Re: [gentoo-user] What to do with /var/run?
I guess the simplest approach is: 1. drop into single user runlevel (`rc single`) 2. move the remnants from /var/run to /run 3. symlink /var/run to /run 4. reboot or go back to default runlevel (`rc default`) /run is a tmpfs mounted at boot time, so anything you copy in there before rebooting will disappear. Ah that makes sense. /run/openerp/ disappears after a reboot and re-emerging openerp brings it back. Should that be an ebuild bug? - Grant Flameeyes was faster: https://bugs.gentoo.org/show_bug.cgi?id=451764 There is a blocker bug for the migration: https://bugs.gentoo.org/show_bug.cgi?id=332633 Diego is using openerp-server and I'm using openerp. So I'm sure I understand, does this mean I should file a keepdirs /var/run bug for openerp? - Grant
Re: [gentoo-user] What to do with /var/run?
Am 16.02.2013 21:08, schrieb Grant: I guess the simplest approach is: 1. drop into single user runlevel (`rc single`) 2. move the remnants from /var/run to /run 3. symlink /var/run to /run 4. reboot or go back to default runlevel (`rc default`) /run is a tmpfs mounted at boot time, so anything you copy in there before rebooting will disappear. Ah that makes sense. /run/openerp/ disappears after a reboot and re-emerging openerp brings it back. Should that be an ebuild bug? - Grant Flameeyes was faster: https://bugs.gentoo.org/show_bug.cgi?id=451764 There is a blocker bug for the migration: https://bugs.gentoo.org/show_bug.cgi?id=332633 Diego is using openerp-server and I'm using openerp. So I'm sure I understand, does this mean I should file a keepdirs /var/run bug for openerp? - Grant If there is no bug referenced as a dependency of the blocker bug I linked, by all means, do it (and reference the blocker bug). signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] What to do with /var/run?
Am 10.02.2013 06:11, schrieb Grant: I received the following ELOG message after an emerge: * One or more symlinks to directories have been preserved in order to * ensure that files installed via these symlinks remain accessible. This * indicates that the mentioned symlink(s) may be obsolete remnants of an * old install, and it may be appropriate to replace a given symlink with * the directory that it points to. * * /var/run Should I change anything? - Grant If my understanding of the situation is correct, we see this message whenever a package is updated that in the old version installed to /var/run and now has migrated to /run. Even if I'm wrong, there is nothing to be done. /var/run is intended to be a symlink to /run. If it is, then all is fine. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] What to do with /var/run?
On Feb 10, 2013 3:29 AM, Florian Philipp li...@binarywings.net wrote: Am 10.02.2013 06:11, schrieb Grant: I received the following ELOG message after an emerge: * One or more symlinks to directories have been preserved in order to * ensure that files installed via these symlinks remain accessible. This * indicates that the mentioned symlink(s) may be obsolete remnants of an * old install, and it may be appropriate to replace a given symlink with * the directory that it points to. * * /var/run Should I change anything? - Grant If my understanding of the situation is correct, we see this message whenever a package is updated that in the old version installed to /var/run and now has migrated to /run. Even if I'm wrong, there is nothing to be done. /var/run is intended to be a symlink to /run. If it is, then all is fine. Regards, Florian Philipp Except we'll be seeing that elog to the end of time lsof -n |grep /var/run will tell you what, if anything running, is using that symlink.
Re: [gentoo-user] What to do with /var/run?
On 10/02/2013 13:49, Michael Mol wrote: On Feb 10, 2013 3:29 AM, Florian Philipp li...@binarywings.net wrote: Am 10.02.2013 06:11, schrieb Grant: I received the following ELOG message after an emerge: * One or more symlinks to directories have been preserved in order to * ensure that files installed via these symlinks remain accessible. This * indicates that the mentioned symlink(s) may be obsolete remnants of an * old install, and it may be appropriate to replace a given symlink with * the directory that it points to. * * /var/run Should I change anything? - Grant If my understanding of the situation is correct, we see this message whenever a package is updated that in the old version installed to /var/run and now has migrated to /run. Even if I'm wrong, there is nothing to be done. /var/run is intended to be a symlink to /run. If it is, then all is fine. Regards, Florian Philipp Except we'll be seeing that elog to the end of time lsof -n |grep /var/run will tell you what, if anything running, is using that symlink. It's probably better to leave the symlink in place for now. What happens when the user installs a package they have never had before and that package uses /var/run? It will make a directory which isn't what you want. Better to leave the symlink in place and train your eyes to ignore the elogs (something we humans are extremely good at) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] What to do with /var/run?
On Sun, Feb 10, 2013 at 7:40 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 10/02/2013 13:49, Michael Mol wrote: On Feb 10, 2013 3:29 AM, Florian Philipp li...@binarywings.net wrote: Am 10.02.2013 06:11, schrieb Grant: I received the following ELOG message after an emerge: * One or more symlinks to directories have been preserved in order to * ensure that files installed via these symlinks remain accessible. This * indicates that the mentioned symlink(s) may be obsolete remnants of an * old install, and it may be appropriate to replace a given symlink with * the directory that it points to. * * /var/run Should I change anything? - Grant If my understanding of the situation is correct, we see this message whenever a package is updated that in the old version installed to /var/run and now has migrated to /run. Even if I'm wrong, there is nothing to be done. /var/run is intended to be a symlink to /run. If it is, then all is fine. Regards, Florian Philipp Except we'll be seeing that elog to the end of time lsof -n |grep /var/run will tell you what, if anything running, is using that symlink. It's probably better to leave the symlink in place for now. What happens when the user installs a package they have never had before and that package uses /var/run? It will make a directory which isn't what you want. Hm. lsof -n|grep /var/run|cut -d\ -f1|sort -u gives me acpid avahi-dae bluetooth cupsd dbus-daem gdm syslog-ng Of those, at least avahi and cups are emitting /var/run elogs, which tells me they're defaulting to using /var/run instead of /run, if /var/run is present. Obviously, the transition isn't finished yet...software should default to /run rather than /var/run, or the symlink can never be known to be safe to remove on a given system. Better to leave the symlink in place and train your eyes to ignore the elogs (something we humans are extremely good at) Oh god no...Then you end up like some folks who get bit every time something changes (despite being warned about it for a months in advance). :) -- :wq
Re: [gentoo-user] What to do with /var/run?
On Sun, 10 Feb 2013 06:49:59 -0500, Michael Mol wrote: If my understanding of the situation is correct, we see this message whenever a package is updated that in the old version installed to /var/run and now has migrated to /run. Even if I'm wrong, there is nothing to be done. /var/run is intended to be a symlink to /run. If it is, then all is fine. Except we'll be seeing that elog to the end of time Not once all package have migrated, if Florian's understanding is correct. lsof -n |grep /var/run will tell you what, if anything running, is using that symlink. It won't tell you about services that have written a pidfile in that directory and then closed the file. Try grep -r /var/run /etc/init.d -- Neil Bothwick Puritanism: The haunting fear that someone, somewhere may be happy. signature.asc Description: PGP signature
Re: [gentoo-user] What to do with /var/run?
On 10/02/2013 15:14, Michael Mol wrote: Better to leave the symlink in place and train your eyes to ignore the elogs (something we humans are extremely good at) Oh god no...Then you end up like some folks who get bit every time something changes (despite being warned about it for a months in advance). :) I've learned to pay no attention to those users, and have an active killfile :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] What to do with /var/run?
Am 10.02.2013 14:14, schrieb Michael Mol: On Sun, Feb 10, 2013 at 7:40 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 10/02/2013 13:49, Michael Mol wrote: On Feb 10, 2013 3:29 AM, Florian Philipp li...@binarywings.net wrote: Am 10.02.2013 06:11, schrieb Grant: I received the following ELOG message after an emerge: * One or more symlinks to directories have been preserved in order to * ensure that files installed via these symlinks remain accessible. This * indicates that the mentioned symlink(s) may be obsolete remnants of an * old install, and it may be appropriate to replace a given symlink with * the directory that it points to. * * /var/run [...] Even if I'm wrong, there is nothing to be done. /var/run is intended to be a symlink to /run. If it is, then all is fine. [...] It's probably better to leave the symlink in place for now. What happens when the user installs a package they have never had before and that package uses /var/run? It will make a directory which isn't what you want. Hm. lsof -n|grep /var/run|cut -d\ -f1|sort -u gives me acpid avahi-dae bluetooth cupsd dbus-daem gdm syslog-ng That's odd. Is your system up-to-date and recently rebooted? I'm running most of these services, too. But I have no open files in /var/run. Of those, at least avahi and cups are emitting /var/run elogs, which tells me they're defaulting to using /var/run instead of /run, if /var/run is present. Obviously, the transition isn't finished yet...software should default to /run rather than /var/run, or the symlink can never be known to be safe to remove on a given system. Better to leave the symlink in place and train your eyes to ignore the elogs (something we humans are extremely good at) Oh god no...Then you end up like some folks who get bit every time something changes (despite being warned about it for a months in advance). :) BTW: Am I the only one annoyed by elog messages like If you are updating from $ANCIENT_VERSION make sure to change $DEPRECATED_FEATURE lurking in the tree for years? Especially because when you see the message, it is a pain in the ass to check which version you were actually using before. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] What to do with /var/run?
Michael Mol mike...@gmail.com wrote: On Sun, Feb 10, 2013 at 7:40 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 10/02/2013 13:49, Michael Mol wrote: On Feb 10, 2013 3:29 AM, Florian Philipp li...@binarywings.net wrote: Am 10.02.2013 06:11, schrieb Grant: I received the following ELOG message after an emerge: * One or more symlinks to directories have been preserved in order to * ensure that files installed via these symlinks remain accessible. This * indicates that the mentioned symlink(s) may be obsolete remnants of an * old install, and it may be appropriate to replace a given symlink with * the directory that it points to. * * /var/run Should I change anything? - Grant If my understanding of the situation is correct, we see this message whenever a package is updated that in the old version installed to /var/run and now has migrated to /run. Even if I'm wrong, there is nothing to be done. /var/run is intended to be a symlink to /run. If it is, then all is fine. Regards, Florian Philipp Except we'll be seeing that elog to the end of time lsof -n |grep /var/run will tell you what, if anything running, is using that symlink. It's probably better to leave the symlink in place for now. What happens when the user installs a package they have never had before and that package uses /var/run? It will make a directory which isn't what you want. Hm. lsof -n|grep /var/run|cut -d\ -f1|sort -u gives me acpid avahi-dae bluetooth cupsd dbus-daem gdm syslog-ng Of those, at least avahi and cups are emitting /var/run elogs, which tells me they're defaulting to using /var/run instead of /run, if /var/run is present. Obviously, the transition isn't finished yet...software should default to /run rather than /var/run, or the symlink can never be known to be safe to remove on a given system. Better to leave the symlink in place and train your eyes to ignore the elogs (something we humans are extremely good at) Oh god no...Then you end up like some folks who get bit every time something changes (despite being warned about it for a months in advance). :) 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. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] What to do with /var/run?
Alan McKinnon wrote: It's probably better to leave the symlink in place for now. What happens when the user installs a package they have never had before and that package uses /var/run? It will make a directory which isn't what you want. Better to leave the symlink in place and train your eyes to ignore the elogs (something we humans are extremely good at) I have a question. On my rig, /var/run does not appear to be a link to /run. For giggles: root@fireball / # ls -al /var/run/ total 132 drwxr-xr-x 17 rootroot 4096 Feb 10 01:46 . drwxr-xr-x 16 rootroot 4096 Feb 8 09:28 .. drwxr-xr-x 2 avahi avahi4096 Feb 8 14:18 avahi-daemon -rwx-- 1 rootroot0 Feb 8 14:18 blocked -rw-r--r-- 1 rootroot5 Feb 10 01:46 chronyd.pid drwxr-xr-x 2 rootroot 4096 Feb 8 18:07 console drwxr-xr-x 2 rootroot 4096 Feb 8 18:07 ConsoleKit -rw-r--r-- 1 rootroot6 Feb 8 14:18 cron.pid drwxr-xr-x 3 rootlp 4096 Feb 9 15:38 cups drwxr-xr-x 2 rootroot 4096 Feb 8 14:18 dbus -rw-r--r-- 1 rootroot6 Feb 8 14:18 dbus.pid drwxr-xr-x 4 rootroot 4096 Jan 2 01:25 dhcpcd -rw-r--r-- 1 rootroot6 Feb 8 14:18 gpm.pid -rw-r--r-- 1 rootroot5 Feb 8 14:18 http-replicator.pid -rw-r--r-- 1 rootroot6 Feb 8 18:06 kdm.pid drwxr-xr-x 2 mysql mysql4096 Jan 30 15:26 mysqld drwxr-xr-x 4 rootroot 4096 Dec 11 2010 pm-utils -rw--- 1 rootroot 512 Jan 12 2012 random-seed -rw-r--r-- 1 rootroot6 Feb 8 14:18 rsyncd.pid drwxrwxr-x 3 rootutmp 4096 May 10 2012 screen -rwx-- 1 rootroot0 Oct 27 17:41 sessiondb.dir -rwx-- 1 rootroot 1024 Feb 8 14:18 sessiondb.pag -rw--- 1 rootroot6 Feb 8 14:18 smartd.pid -rw-r--r-- 1 rootroot6 Feb 8 14:18 sshd.pid srwxr-xr-x 1 rootroot0 Feb 8 14:18 syslog-ng.ctl -rw-r--r-- 1 rootroot6 Feb 8 14:18 syslog-ng.pid drwxr-xr-x 2 tor tor 4096 Nov 19 02:27 tor drwxr-xr-x 2 rootroot 4096 Oct 27 17:40 udev-configure-printer drwx-- 2 rootroot 4096 Oct 3 2011 udisks -rw-r--r-- 1 rootroot6 Feb 8 14:18 upsmon.pid drwxr-xr-x 2 uptimed uptimed 4096 Jan 31 06:15 uptimed -rw-rw-r-- 1 rootutmp10368 Feb 8 18:07 utmp drwxr-xr-x 2 rootroot 4096 Feb 8 18:07 xauth drwxr-xr-x 4 rootroot 4096 Feb 8 18:06 xdmctl root@fireball / # ls -al /run/ total 4 drwxrwxrwt 7 root root 140 Feb 8 07:49 . drwxr-xr-x 23 root root 4096 Feb 9 15:27 .. drwxr-xr-x 2 root root 80 Dec 6 15:42 blkid drwxr-xr-x 3 root uucp 60 Sep 23 10:17 lock drwxr-xr-x 14 root root 360 Feb 8 14:18 openrc drwxr-xr-x 7 root root 180 Feb 9 17:27 udev drwx-- 2 root root 40 Feb 8 07:49 udisks2 root@fireball / # ls /var/ total 76 drwxr-xr-x 16 root root 4096 Feb 8 09:28 . drwxr-xr-x 23 root root 4096 Feb 9 15:27 .. drwxr-xr-x 2 root root 4096 Feb 8 12:05 account drwxr-xr-x 12 root root 4096 Dec 20 11:38 cache drwxr-xr-x 5 root root 4096 Feb 9 14:25 db drwx-- 3 root root 4096 Feb 8 13:32 empty -rw-r- 1 root root 0 Apr 12 2012 hp-toolbox.lock drwxr-xr-x 32 root root 4096 Feb 7 23:57 lib drwxrwxr-x 5 root uucp 4096 Feb 10 03:10 lock drwxr-xr-x 14 root root 4096 Feb 10 03:10 log drwx-- 2 root root 16384 Mar 17 2012 lost+found lrwxrwxrwx 1 root root15 Feb 8 09:28 mail - /var/spool/mail drwxr-xr-x 17 root root 4096 Feb 10 01:46 run drwxr-xr-x 6 root root 4096 Dec 11 2010 spool drwxr-xr-x 2 root root 4096 Nov 17 2010 state drwxrwxrwt 13 root root 4096 Feb 9 15:23 tmp drwx-- 4 root root 4096 Jun 28 2012 .Trash-0 drwxr-xr-x 3 root root 4096 Dec 11 2010 www root@fireball / # See, the contents of those two are different and the listing for /for shows it is not a symlink. Should I fix this manually or leave it as is? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] What to do with /var/run?
On 10/02/2013 17:29, cov...@ccs.covici.com 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 -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] What to do with /var/run?
On 10/02/2013 17:53, Dale wrote: Alan McKinnon wrote: It's probably better to leave the symlink in place for now. What happens when the user installs a package they have never had before and that package uses /var/run? It will make a directory which isn't what you want. Better to leave the symlink in place and train your eyes to ignore the elogs (something we humans are extremely good at) I have a question. On my rig, /var/run does not appear to be a link to /run. For giggles: You should re-read the elog you got when /run was created and do what it says :-) root@fireball / # ls -al /var/run/ total 132 drwxr-xr-x 17 rootroot 4096 Feb 10 01:46 . drwxr-xr-x 16 rootroot 4096 Feb 8 09:28 .. drwxr-xr-x 2 avahi avahi4096 Feb 8 14:18 avahi-daemon -rwx-- 1 rootroot0 Feb 8 14:18 blocked -rw-r--r-- 1 rootroot5 Feb 10 01:46 chronyd.pid drwxr-xr-x 2 rootroot 4096 Feb 8 18:07 console drwxr-xr-x 2 rootroot 4096 Feb 8 18:07 ConsoleKit -rw-r--r-- 1 rootroot6 Feb 8 14:18 cron.pid drwxr-xr-x 3 rootlp 4096 Feb 9 15:38 cups drwxr-xr-x 2 rootroot 4096 Feb 8 14:18 dbus -rw-r--r-- 1 rootroot6 Feb 8 14:18 dbus.pid drwxr-xr-x 4 rootroot 4096 Jan 2 01:25 dhcpcd -rw-r--r-- 1 rootroot6 Feb 8 14:18 gpm.pid -rw-r--r-- 1 rootroot5 Feb 8 14:18 http-replicator.pid -rw-r--r-- 1 rootroot6 Feb 8 18:06 kdm.pid drwxr-xr-x 2 mysql mysql4096 Jan 30 15:26 mysqld drwxr-xr-x 4 rootroot 4096 Dec 11 2010 pm-utils -rw--- 1 rootroot 512 Jan 12 2012 random-seed -rw-r--r-- 1 rootroot6 Feb 8 14:18 rsyncd.pid drwxrwxr-x 3 rootutmp 4096 May 10 2012 screen -rwx-- 1 rootroot0 Oct 27 17:41 sessiondb.dir -rwx-- 1 rootroot 1024 Feb 8 14:18 sessiondb.pag -rw--- 1 rootroot6 Feb 8 14:18 smartd.pid -rw-r--r-- 1 rootroot6 Feb 8 14:18 sshd.pid srwxr-xr-x 1 rootroot0 Feb 8 14:18 syslog-ng.ctl -rw-r--r-- 1 rootroot6 Feb 8 14:18 syslog-ng.pid drwxr-xr-x 2 tor tor 4096 Nov 19 02:27 tor drwxr-xr-x 2 rootroot 4096 Oct 27 17:40 udev-configure-printer drwx-- 2 rootroot 4096 Oct 3 2011 udisks -rw-r--r-- 1 rootroot6 Feb 8 14:18 upsmon.pid drwxr-xr-x 2 uptimed uptimed 4096 Jan 31 06:15 uptimed -rw-rw-r-- 1 rootutmp10368 Feb 8 18:07 utmp drwxr-xr-x 2 rootroot 4096 Feb 8 18:07 xauth drwxr-xr-x 4 rootroot 4096 Feb 8 18:06 xdmctl root@fireball / # ls -al /run/ total 4 drwxrwxrwt 7 root root 140 Feb 8 07:49 . drwxr-xr-x 23 root root 4096 Feb 9 15:27 .. drwxr-xr-x 2 root root 80 Dec 6 15:42 blkid drwxr-xr-x 3 root uucp 60 Sep 23 10:17 lock drwxr-xr-x 14 root root 360 Feb 8 14:18 openrc drwxr-xr-x 7 root root 180 Feb 9 17:27 udev drwx-- 2 root root 40 Feb 8 07:49 udisks2 root@fireball / # ls /var/ total 76 drwxr-xr-x 16 root root 4096 Feb 8 09:28 . drwxr-xr-x 23 root root 4096 Feb 9 15:27 .. drwxr-xr-x 2 root root 4096 Feb 8 12:05 account drwxr-xr-x 12 root root 4096 Dec 20 11:38 cache drwxr-xr-x 5 root root 4096 Feb 9 14:25 db drwx-- 3 root root 4096 Feb 8 13:32 empty -rw-r- 1 root root 0 Apr 12 2012 hp-toolbox.lock drwxr-xr-x 32 root root 4096 Feb 7 23:57 lib drwxrwxr-x 5 root uucp 4096 Feb 10 03:10 lock drwxr-xr-x 14 root root 4096 Feb 10 03:10 log drwx-- 2 root root 16384 Mar 17 2012 lost+found lrwxrwxrwx 1 root root15 Feb 8 09:28 mail - /var/spool/mail drwxr-xr-x 17 root root 4096 Feb 10 01:46 run drwxr-xr-x 6 root root 4096 Dec 11 2010 spool drwxr-xr-x 2 root root 4096 Nov 17 2010 state drwxrwxrwt 13 root root 4096 Feb 9 15:23 tmp drwx-- 4 root root 4096 Jun 28 2012 .Trash-0 drwxr-xr-x 3 root root 4096 Dec 11 2010 www root@fireball / # See, the contents of those two are different and the listing for /for shows it is not a symlink. Should I fix this manually or leave it as is? Dale :-) :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] What to do with /var/run?
Alan McKinnon wrote: On 10/02/2013 17:53, Dale wrote: Alan McKinnon wrote: It's probably better to leave the symlink in place for now. What happens when the user installs a package they have never had before and that package uses /var/run? It will make a directory which isn't what you want. Better to leave the symlink in place and train your eyes to ignore the elogs (something we humans are extremely good at) I have a question. On my rig, /var/run does not appear to be a link to /run. For giggles: You should re-read the elog you got when /run was created and do what it says :-) Actually, I had something that wouldn't start and said it needed /run. I didn't have one, found references with google that it was the new and upcoming thing, so I created it myself. So, it must have been a bug that should have been reported but I didn't realize that. By creating it myself, I created a bit of a problem. Now what to do about it. I don't see any news item or anything on it. I generally look at elogs but we know how that works. lol I guess I missed that one. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] What to do with /var/run?
Alan McKinnon alan.mckin...@gmail.com wrote: On 10/02/2013 17:29, cov...@ccs.covici.com 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. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] What to do with /var/run?
Am 10.02.2013 17:39, schrieb Dale: [...] Actually, I had something that wouldn't start and said it needed /run. I didn't have one, found references with google that it was the new and upcoming thing, so I created it myself. So, it must have been a bug that should have been reported but I didn't realize that. By creating it myself, I created a bit of a problem. Now what to do about it. I guess the simplest approach is: 1. drop into single user runlevel (`rc single`) 2. move the remnants from /var/run to /run 3. symlink /var/run to /run 4. reboot or go back to default runlevel (`rc default`) Hope this helps, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] What to do with /var/run?
Am 10.02.2013 17:46, schrieb cov...@ccs.covici.com: Alan McKinnon alan.mckin...@gmail.com wrote: On 10/02/2013 17:29, cov...@ccs.covici.com 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. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] What to do with /var/run?
Florian Philipp wrote: Am 10.02.2013 17:39, schrieb Dale: [...] Actually, I had something that wouldn't start and said it needed /run. I didn't have one, found references with google that it was the new and upcoming thing, so I created it myself. So, it must have been a bug that should have been reported but I didn't realize that. By creating it myself, I created a bit of a problem. Now what to do about it. I guess the simplest approach is: 1. drop into single user runlevel (`rc single`) 2. move the remnants from /var/run to /run 3. symlink /var/run to /run 4. reboot or go back to default runlevel (`rc default`) Hope this helps, Florian Philipp Since you mention rc single. I did that a good while back. Afterwards I went to boot runlevel then to the default runlevel. When I got to the default runlevel, it was not working like it should. I rebooted and everything was back to normal. Have you ever ran into that? It's been a while, most likely when the openrc change was going on. Just curious. I may give that a try. That sounds like a plan. I'll be ready for a reboot tho, just in case. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] What to do with /var/run?
On Sun, 10 Feb 2013 17:56:45 +0100, Florian Philipp wrote: I guess the simplest approach is: 1. drop into single user runlevel (`rc single`) 2. move the remnants from /var/run to /run 3. symlink /var/run to /run 4. reboot or go back to default runlevel (`rc default`) /run is a tmpfs mounted at boot time, so anything you copy in there before rebooting will disappear. -- Neil Bothwick Love is grand. Divorce is a few grand more. signature.asc Description: PGP signature
Re: [gentoo-user] What to do with /var/run?
On Sun, 10 Feb 2013 14:42:17 +0100, Florian Philipp wrote: BTW: Am I the only one annoyed by elog messages like If you are updating from $ANCIENT_VERSION make sure to change $DEPRECATED_FEATURE lurking in the tree for years? Especially because when you see the message, it is a pain in the ass to check which version you were actually using before. No. -- Neil Bothwick I just took an IQ test. The results were negative. signature.asc Description: PGP signature
Re: [gentoo-user] What to do with /var/run?
Am 10.02.2013 18:56, schrieb Neil Bothwick: On Sun, 10 Feb 2013 17:56:45 +0100, Florian Philipp wrote: I guess the simplest approach is: 1. drop into single user runlevel (`rc single`) 2. move the remnants from /var/run to /run 3. symlink /var/run to /run 4. reboot or go back to default runlevel (`rc default`) /run is a tmpfs mounted at boot time, so anything you copy in there before rebooting will disappear. I know. I considered omitting that step. However, I'm not sure what exactly keeps running in `rc single` and some stuff in /run looks like it might be necessary for a clean shutdown. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] What to do with /var/run?
Florian Philipp li...@binarywings.net wrote: Am 10.02.2013 17:46, schrieb cov...@ccs.covici.com: Alan McKinnon alan.mckin...@gmail.com wrote: On 10/02/2013 17:29, cov...@ccs.covici.com 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 -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] What to do with /var/run?
Am 10.02.2013 19:01, schrieb cov...@ccs.covici.com: Florian Philipp li...@binarywings.net wrote: Am 10.02.2013 17:46, schrieb cov...@ccs.covici.com: Alan McKinnon alan.mckin...@gmail.com wrote: On 10/02/2013 17:29, cov...@ccs.covici.com 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 https://bugs.gentoo.org/show_bug.cgi?id=454676 /var/run/dbus https://bugs.gentoo.org/show_bug.cgi?id=387897 Fixed in stable. /var/run/named https://bugs.gentoo.org/show_bug.cgi?id=334535 Fixed in stable. /var/run/fail2ban https://bugs.gentoo.org/show_bug.cgi?id=449966 Fixed without a revision bump. /var/run/asterisk https://bugs.gentoo.org/show_bug.cgi?id=451808 https://bugs.gentoo.org/show_bug.cgi?id=445182 https://bugs.gentoo.org/show_bug.cgi?id=450222 Fixed in stable. /var/run/freeswitch Guess this goes nowhere with maintainer-needed status. https://bugs.gentoo.org/show_bug.cgi?id=150527 /var/run/wpa_supplicant https://bugs.gentoo.org/show_bug.cgi?id=387895 Works for me with /var/run symlink. /var/run/gdm /var/run/gdm/greeter /var/run/gdm/auth-for-gdm-GtotHP Should work or more people would complain. /var/run/openldap https://bugs.gentoo.org/show_bug.cgi?id=444912 Fixed in testing. /var/run/dhcpcd /var/run/dhcpcd/ntp.conf /var/run/dhcpcd/resolv.conf Works for me. /var/run/pulse https://bugs.gentoo.org/show_bug.cgi?id=442852 /var/run/mysqld Works for me. /var/run/cups https://bugs.gentoo.org/show_bug.cgi?id=451756 Works for me. /var/run/cups/certs https://bugs.gentoo.org/show_bug.cgi?id=387893 Fixed in stable. /var/run/radvd https://bugs.gentoo.org/show_bug.cgi?id=453140 Fixed in stable. /var/run/pm-utils /var/run/pm-utils/locks /var/run/pm-utils/pm-powersave /var/run/pm-utils/pm-powersave/storage Works for me. /var/run/proftpd https://bugs.gentoo.org/show_bug.cgi?id=449360 https://bugs.gentoo.org/show_bug.cgi?id=387889 Fixed in testing. /var/run/dhcp https://bugs.gentoo.org/show_bug.cgi?id=446446 Fixed in stable. /var/run/udisks https://bugs.gentoo.org/show_bug.cgi?id=333893 Fixed in stable. /var/run/spamd https://bugs.gentoo.org/show_bug.cgi?id=455604 /var/run/ConsoleKit https://bugs.gentoo.org/show_bug.cgi?id=450224 https://bugs.gentoo.org/show_bug.cgi?id=387901 Works for me. /var/run/console Works for me. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] What to do with /var/run?
Florian Philipp li...@binarywings.net wrote: Am 10.02.2013 19:01, schrieb cov...@ccs.covici.com: Florian Philipp li...@binarywings.net wrote: Am 10.02.2013 17:46, schrieb cov...@ccs.covici.com: Alan McKinnon alan.mckin...@gmail.com wrote: On 10/02/2013 17:29, cov...@ccs.covici.com 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 https://bugs.gentoo.org/show_bug.cgi?id=454676 /var/run/dbus https://bugs.gentoo.org/show_bug.cgi?id=387897 Fixed in stable. /var/run/named https://bugs.gentoo.org/show_bug.cgi?id=334535 Fixed in stable. /var/run/fail2ban https://bugs.gentoo.org/show_bug.cgi?id=449966 Fixed without a revision bump. /var/run/asterisk https://bugs.gentoo.org/show_bug.cgi?id=451808 https://bugs.gentoo.org/show_bug.cgi?id=445182 https://bugs.gentoo.org/show_bug.cgi?id=450222 Fixed in stable. /var/run/freeswitch Guess this goes nowhere with maintainer-needed status. https://bugs.gentoo.org/show_bug.cgi?id=150527 /var/run/wpa_supplicant https://bugs.gentoo.org/show_bug.cgi?id=387895 Works for me with /var/run symlink. /var/run/gdm /var/run/gdm/greeter /var/run/gdm/auth-for-gdm-GtotHP Should work or more people would complain. /var/run/openldap https://bugs.gentoo.org/show_bug.cgi?id=444912 Fixed in testing. /var/run/dhcpcd /var/run/dhcpcd/ntp.conf /var/run/dhcpcd/resolv.conf Works for me. /var/run/pulse https://bugs.gentoo.org/show_bug.cgi?id=442852 /var/run/mysqld Works for me. /var/run/cups https://bugs.gentoo.org/show_bug.cgi?id=451756 Works for me. /var/run/cups/certs https://bugs.gentoo.org/show_bug.cgi?id=387893 Fixed in stable. /var/run/radvd https://bugs.gentoo.org/show_bug.cgi?id=453140 Fixed in stable. /var/run/pm-utils /var/run/pm-utils/locks /var/run/pm-utils/pm-powersave /var/run/pm-utils/pm-powersave/storage Works for me. /var/run/proftpd https://bugs.gentoo.org/show_bug.cgi?id=449360 https://bugs.gentoo.org/show_bug.cgi?id=387889 Fixed in testing. /var/run/dhcp https://bugs.gentoo.org/show_bug.cgi?id=446446 Fixed in stable. /var/run/udisks https://bugs.gentoo.org/show_bug.cgi?id=333893 Fixed in stable. /var/run/spamd https://bugs.gentoo.org/show_bug.cgi?id=455604 /var/run/ConsoleKit https://bugs.gentoo.org/show_bug.cgi?id=450224 https://bugs.gentoo.org/show_bug.cgi?id=387901 Works for me. /var/run/console Works for me. Thanks -- I will have to investigate the ones you say are fixed and see why they didn't work or which ones did not. Innd is another matter with its wanting /var/lock/news and the /var/lock permissions were wrong, but I can fix that. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it?
Re: [gentoo-user] What to do with /var/run?
I guess the simplest approach is: 1. drop into single user runlevel (`rc single`) 2. move the remnants from /var/run to /run 3. symlink /var/run to /run 4. reboot or go back to default runlevel (`rc default`) /run is a tmpfs mounted at boot time, so anything you copy in there before rebooting will disappear. Ah that makes sense. /run/openerp/ disappears after a reboot and re-emerging openerp brings it back. Should that be an ebuild bug? - Grant
Re: [gentoo-user] What to do with /var/run?
Am 10.02.2013 20:17, schrieb Grant: I guess the simplest approach is: 1. drop into single user runlevel (`rc single`) 2. move the remnants from /var/run to /run 3. symlink /var/run to /run 4. reboot or go back to default runlevel (`rc default`) /run is a tmpfs mounted at boot time, so anything you copy in there before rebooting will disappear. Ah that makes sense. /run/openerp/ disappears after a reboot and re-emerging openerp brings it back. Should that be an ebuild bug? - Grant Flameeyes was faster: https://bugs.gentoo.org/show_bug.cgi?id=451764 There is a blocker bug for the migration: https://bugs.gentoo.org/show_bug.cgi?id=332633 Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] What to do with /var/run?
On 10/02/2013 20:01, cov...@ccs.covici.com wrote: Florian Philipp li...@binarywings.net wrote: Am 10.02.2013 17:46, schrieb cov...@ccs.covici.com: Alan McKinnon alan.mckin...@gmail.com wrote: On 10/02/2013 17:29, cov...@ccs.covici.com 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 alan.mckin...@gmail.com
Re: [gentoo-user] What to do with /var/run?
Alan McKinnon alan.mckin...@gmail.com wrote: On 10/02/2013 20:01, cov...@ccs.covici.com wrote: Florian Philipp li...@binarywings.net wrote: Am 10.02.2013 17:46, schrieb cov...@ccs.covici.com: Alan McKinnon alan.mckin...@gmail.com wrote: On 10/02/2013 17:29, cov...@ccs.covici.com 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) Sure, I did delete the symlink when things stopped working properly. I then copied a previous /var/run, deleted all the .pid files, changed /var/lock permissions -- which did not work for me -- fixed that up, deleted the migration step out of bootmisc, and I was back to things working again. I don't disagree that I should fix things up, but /var gets mounted early enough so things happen correctly, so things just work. I haven't tried to create /run in my actual root file system, but there may be some possible problems doing that as well, so I will go through when I have more free time and fix up directories and permissions so migration will work properly. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] What to do with /var/run?
Grant emailgr...@gmail.com wrote: I received the following ELOG message after an emerge: * One or more symlinks to directories have been preserved in order to * ensure that files installed via these symlinks remain accessible. This * indicates that the mentioned symlink(s) may be obsolete remnants of an * old install, and it may be appropriate to replace a given symlink with * the directory that it points to. * * /var/run Should I change anything? - Grant If you do shorewall safe-restart (not using the init-script) you see logging on the screen. -- Joost Roeleveld -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] What to do with /var/run?
J. Roeleveld jo...@antarean.org wrote: Grant emailgr...@gmail.com wrote: I received the following ELOG message after an emerge: * One or more symlinks to directories have been preserved in order to * ensure that files installed via these symlinks remain accessible. This * indicates that the mentioned symlink(s) may be obsolete remnants of an * old install, and it may be appropriate to replace a given symlink with * the directory that it points to. * * /var/run Should I change anything? - Grant If you do shorewall safe-restart (not using the init-script) you see logging on the screen. -- Joost Roeleveld Oops... Replied on wrong thread. This was meant for the shorewall one. I blame the mail client on the phone... -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
