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