[gentoo-user] What to do with /var/run?

[gentoo-user] What to do with /var/run?

[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

Re: [gentoo-user] What to do with /var/run?

[J. Roeleveld]

Grant <emailgrant@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]

"J. Roeleveld" <joost@antarean.org> wrote:

>Grant <emailgrant@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.

Re: [gentoo-user] What to do with /var/run?

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [gentoo-user] What to do with /var/run?

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]

On Feb 10, 2013 3:29 AM, "Florian Philipp" <lists@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.

[-- Attachment #2: Type: text/html, Size: 1507 bytes --]

Re: [gentoo-user] What to do with /var/run?

[Alan McKinnon]

On 10/02/2013 13:49, Michael Mol wrote:
> On Feb 10, 2013 3:29 AM, "Florian Philipp" <lists@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.mckinnon@gmail.com

Re: [gentoo-user] What to do with /var/run?

[Michael Mol]

On Sun, Feb 10, 2013 at 7:40 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 10/02/2013 13:49, Michael Mol wrote:
>> On Feb 10, 2013 3:29 AM, "Florian Philipp" <lists@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?

[Alan McKinnon]

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.mckinnon@gmail.com

Re: [gentoo-user] What to do with /var/run?

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]

Am 10.02.2013 14:14, schrieb Michael Mol:
> On Sun, Feb 10, 2013 at 7:40 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> On 10/02/2013 13:49, Michael Mol wrote:
>>> On Feb 10, 2013 3:29 AM, "Florian Philipp" <lists@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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [gentoo-user] What to do with /var/run?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] What to do with /var/run?

[covici]

Michael Mol <mikemol@gmail.com> wrote:

> On Sun, Feb 10, 2013 at 7:40 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> > On 10/02/2013 13:49, Michael Mol wrote:
> >> On Feb 10, 2013 3:29 AM, "Florian Philipp" <lists@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
         covici@ccs.covici.com

Re: [gentoo-user] What to do with /var/run?

[Alan McKinnon]

On 10/02/2013 17:29, covici@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.mckinnon@gmail.com

Re: [gentoo-user] What to do with /var/run?

[covici]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 10/02/2013 17:29, covici@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
         covici@ccs.covici.com

Re: [gentoo-user] What to do with /var/run?

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]

Am 10.02.2013 17:46, schrieb covici@ccs.covici.com:
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
>> On 10/02/2013 17:29, covici@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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [gentoo-user] What to do with /var/run?

[covici]

Florian Philipp <lists@binarywings.net> wrote:

> Am 10.02.2013 17:46, schrieb covici@ccs.covici.com:
> > Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> > 
> >> On 10/02/2013 17:29, covici@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
         covici@ccs.covici.com

Re: [gentoo-user] What to do with /var/run?

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 4825 bytes --]

Am 10.02.2013 19:01, schrieb covici@ccs.covici.com:
> Florian Philipp <lists@binarywings.net> wrote:
> 
>> Am 10.02.2013 17:46, schrieb covici@ccs.covici.com:
>>> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>>
>>>> On 10/02/2013 17:29, covici@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [gentoo-user] What to do with /var/run?

[covici]

Florian Philipp <lists@binarywings.net> wrote:

> Am 10.02.2013 19:01, schrieb covici@ccs.covici.com:
> > Florian Philipp <lists@binarywings.net> wrote:
> > 
> >> Am 10.02.2013 17:46, schrieb covici@ccs.covici.com:
> >>> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> >>>
> >>>> On 10/02/2013 17:29, covici@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?

         John Covici
         covici@ccs.covici.com

Re: [gentoo-user] What to do with /var/run?

[Alan McKinnon]

On 10/02/2013 20:01, covici@ccs.covici.com wrote:
> Florian Philipp <lists@binarywings.net> wrote:
> 
>> Am 10.02.2013 17:46, schrieb covici@ccs.covici.com:
>>> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>>
>>>> On 10/02/2013 17:29, covici@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.mckinnon@gmail.com

Re: [gentoo-user] What to do with /var/run?

[covici]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 10/02/2013 20:01, covici@ccs.covici.com wrote:
> > Florian Philipp <lists@binarywings.net> wrote:
> > 
> >> Am 10.02.2013 17:46, schrieb covici@ccs.covici.com:
> >>> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> >>>
> >>>> On 10/02/2013 17:29, covici@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
         covici@ccs.covici.com

Re: [gentoo-user] What to do with /var/run?

[Dale]

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 root    root     4096 Feb 10 01:46 .
drwxr-xr-x 16 root    root     4096 Feb  8 09:28 ..
drwxr-xr-x  2 avahi   avahi    4096 Feb  8 14:18 avahi-daemon
-rwx------  1 root    root        0 Feb  8 14:18 blocked
-rw-r--r--  1 root    root        5 Feb 10 01:46 chronyd.pid
drwxr-xr-x  2 root    root     4096 Feb  8 18:07 console
drwxr-xr-x  2 root    root     4096 Feb  8 18:07 ConsoleKit
-rw-r--r--  1 root    root        6 Feb  8 14:18 cron.pid
drwxr-xr-x  3 root    lp       4096 Feb  9 15:38 cups
drwxr-xr-x  2 root    root     4096 Feb  8 14:18 dbus
-rw-r--r--  1 root    root        6 Feb  8 14:18 dbus.pid
drwxr-xr-x  4 root    root     4096 Jan  2 01:25 dhcpcd
-rw-r--r--  1 root    root        6 Feb  8 14:18 gpm.pid
-rw-r--r--  1 root    root        5 Feb  8 14:18 http-replicator.pid
-rw-r--r--  1 root    root        6 Feb  8 18:06 kdm.pid
drwxr-xr-x  2 mysql   mysql    4096 Jan 30 15:26 mysqld
drwxr-xr-x  4 root    root     4096 Dec 11  2010 pm-utils
-rw-------  1 root    root      512 Jan 12  2012 random-seed
-rw-r--r--  1 root    root        6 Feb  8 14:18 rsyncd.pid
drwxrwxr-x  3 root    utmp     4096 May 10  2012 screen
-rwx------  1 root    root        0 Oct 27 17:41 sessiondb.dir
-rwx------  1 root    root     1024 Feb  8 14:18 sessiondb.pag
-rw-------  1 root    root        6 Feb  8 14:18 smartd.pid
-rw-r--r--  1 root    root        6 Feb  8 14:18 sshd.pid
srwxr-xr-x  1 root    root        0 Feb  8 14:18 syslog-ng.ctl
-rw-r--r--  1 root    root        6 Feb  8 14:18 syslog-ng.pid
drwxr-xr-x  2 tor     tor      4096 Nov 19 02:27 tor
drwxr-xr-x  2 root    root     4096 Oct 27 17:40 udev-configure-printer
drwx------  2 root    root     4096 Oct  3  2011 udisks
-rw-r--r--  1 root    root        6 Feb  8 14:18 upsmon.pid
drwxr-xr-x  2 uptimed uptimed  4096 Jan 31 06:15 uptimed
-rw-rw-r--  1 root    utmp    10368 Feb  8 18:07 utmp
drwxr-xr-x  2 root    root     4096 Feb  8 18:07 xauth
drwxr-xr-x  4 root    root     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 root    15 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?

[Alan McKinnon]

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 root    root     4096 Feb 10 01:46 .
> drwxr-xr-x 16 root    root     4096 Feb  8 09:28 ..
> drwxr-xr-x  2 avahi   avahi    4096 Feb  8 14:18 avahi-daemon
> -rwx------  1 root    root        0 Feb  8 14:18 blocked
> -rw-r--r--  1 root    root        5 Feb 10 01:46 chronyd.pid
> drwxr-xr-x  2 root    root     4096 Feb  8 18:07 console
> drwxr-xr-x  2 root    root     4096 Feb  8 18:07 ConsoleKit
> -rw-r--r--  1 root    root        6 Feb  8 14:18 cron.pid
> drwxr-xr-x  3 root    lp       4096 Feb  9 15:38 cups
> drwxr-xr-x  2 root    root     4096 Feb  8 14:18 dbus
> -rw-r--r--  1 root    root        6 Feb  8 14:18 dbus.pid
> drwxr-xr-x  4 root    root     4096 Jan  2 01:25 dhcpcd
> -rw-r--r--  1 root    root        6 Feb  8 14:18 gpm.pid
> -rw-r--r--  1 root    root        5 Feb  8 14:18 http-replicator.pid
> -rw-r--r--  1 root    root        6 Feb  8 18:06 kdm.pid
> drwxr-xr-x  2 mysql   mysql    4096 Jan 30 15:26 mysqld
> drwxr-xr-x  4 root    root     4096 Dec 11  2010 pm-utils
> -rw-------  1 root    root      512 Jan 12  2012 random-seed
> -rw-r--r--  1 root    root        6 Feb  8 14:18 rsyncd.pid
> drwxrwxr-x  3 root    utmp     4096 May 10  2012 screen
> -rwx------  1 root    root        0 Oct 27 17:41 sessiondb.dir
> -rwx------  1 root    root     1024 Feb  8 14:18 sessiondb.pag
> -rw-------  1 root    root        6 Feb  8 14:18 smartd.pid
> -rw-r--r--  1 root    root        6 Feb  8 14:18 sshd.pid
> srwxr-xr-x  1 root    root        0 Feb  8 14:18 syslog-ng.ctl
> -rw-r--r--  1 root    root        6 Feb  8 14:18 syslog-ng.pid
> drwxr-xr-x  2 tor     tor      4096 Nov 19 02:27 tor
> drwxr-xr-x  2 root    root     4096 Oct 27 17:40 udev-configure-printer
> drwx------  2 root    root     4096 Oct  3  2011 udisks
> -rw-r--r--  1 root    root        6 Feb  8 14:18 upsmon.pid
> drwxr-xr-x  2 uptimed uptimed  4096 Jan 31 06:15 uptimed
> -rw-rw-r--  1 root    utmp    10368 Feb  8 18:07 utmp
> drwxr-xr-x  2 root    root     4096 Feb  8 18:07 xauth
> drwxr-xr-x  4 root    root     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 root    15 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.mckinnon@gmail.com

Re: [gentoo-user] What to do with /var/run?

[Dale]

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?

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [gentoo-user] What to do with /var/run?

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

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!


[-- Attachment #2: Type: text/html, Size: 1977 bytes --]

Re: [gentoo-user] What to do with /var/run?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] What to do with /var/run?

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [gentoo-user] What to do with /var/run?

[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

Re: [gentoo-user] What to do with /var/run?

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [gentoo-user] What to do with /var/run?

[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

Re: [gentoo-user] What to do with /var/run?

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

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).


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [gentoo-user] What to do with /var/run?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]