On 10/02/2013 20:01, [email protected] wrote: > Florian Philipp <[email protected]> wrote: > >> Am 10.02.2013 17:46, schrieb [email protected]: >>> Alan McKinnon <[email protected]> wrote: >>> >>>> On 10/02/2013 17:29, [email protected] wrote: >>>>> I had to actually prevent the migration to /run by changing the >>>>> boot.misc script because if I do not do that, a number of subdirectories >>>>> which I had created in /var/run were not in /run and a number of apps >>>>> would not start properly and indeed it is not taking much space, so I am >>>>> not sure why anyone bothered. The only other option would have been to >>>>> write something to fix the /run, but that was not what I wanted to do. >>>>> /var/lock had this same problem also. >>>> >>>> Why would you do that? >>>> >>>> /var/run is broken as the destination folder for what is intended to go >>>> in it, and it has been broken since day 1: >>>> >>>> /var/run is only available once /var is available or mounted. >>>> The contents of /var/run are often needed before /var is mounted. >>>> /run is the correct place for this. >>>> >>>> Problems with the migration are solved using the mv command >>> >>> But when I let the migration happen -- which was something udev or >>> openrc did -- then certain things in my runlevels would not start >>> because subdirectories in /var/run which were needed were missing and >>> had t o have correct owners and permissions. /var/lock needed certain >>> subdirectories also such as news. Only way to get them to work under >>> /run would be to have a script to run after boot.misc which created all >>> the subdirectories and fixed all the owners and permissions which is a >>> lot more work -- and it would of course have to be done on each reboot. >>> >>> >> >> Are these init scripts from packages in the official tree, something you >> wrote yourself or some third-party package? >> >> In the first case, check if the problem persists (I bet it's fixed now) >> and file a bug report. >> >> In the second case, the best approach is to patch your scripts to use >> the `checkpath` command (see `man runscript`) to ensure that the >> expected paths exist. > > As far as I remember, these are all packages from the tree and I am > using unstable, so I would have to file a number of bug reports. > There are a few things such as freeswitch which I could fix in its > startup script, but here is the result of > find /var/run -type d > and I would also have to fix owners and permissions unless the package > maintainers fix things. > > /var/run/samba > /var/run/dbus > /var/run/named > /var/run/fail2ban > /var/run/asterisk > /var/run/freeswitch > /var/run/wpa_supplicant > /var/run/gdm > /var/run/gdm/greeter > /var/run/gdm/auth-for-gdm-GtotHP > /var/run/openldap > /var/run/dhcpcd > /var/run/dhcpcd/ntp.conf > /var/run/dhcpcd/resolv.conf > /var/run/pulse > /var/run/mysqld > /var/run/cups > /var/run/cups/certs > /var/run/radvd > /var/run/pm-utils > /var/run/pm-utils/locks > /var/run/pm-utils/pm-powersave > /var/run/pm-utils/pm-powersave/storage > /var/run/proftpd > /var/run/dhcp > /var/run/udisks > /var/run/spamd > /var/run/ConsoleKit > /var/run/console >
- bind-mount the partition /var/run is on to somewhere so you can get at the real contents without another mount getting in the way - mv -i /var/run/* /run - rmdir /var/run - ln -sfn /run /var/run That's how you would do it manually. There was a migration step that did it for your automatically, but I forget when that was (a while ago?) If those simple steps cause things to break for you, then something is badly wrong with your system, as the about is exactly how symlinks are supposed to work on Unix, they should be transparent and break nothing. This must always work as /run is guaranteed to be available before /var/run and to go away later. The only underlying cause I can think of for your troubles is that the symlink was never created or you deleted it, more likely the latter (no offense, i call it as I see it) -- Alan McKinnon [email protected]
