Re: Request for testing: /run and initscripts

[Goswin von Brederlow <goswin-v-b@web.de>]

Edward Allcutt <edward@allcutt.me.uk> writes:

> On Fri, 15 Apr 2011, Roger Leigh wrote:
>> This I really don't get.  There was no error reported, and we're using
>> this logic:
>>
>> if [ ! -L /var/run ] && [ -d /var/run ]; then
>>    echo "guest environment detected: Migrating /var/run to /run"
>>    ( # Remove /run first, so all contents get moved
>>      rm -fr /run &&
>>      mv /var/run / &&
>>      ln -fs /run /var/run ) ||
>>      ( echo "Can't move /var/run to /run and replace with symlink; please fix manually."; exit 1 )
>> fi
>
> So, er, /var/run is going to be missing for an appreciable length of time. Is

"appreciable length of time"? The time to do an atomic mv (not the copy
fallback) followed by ln should be unnoticable and suitable hard to hit
by any running program.

> this acceptable? Also, if /var is not on the / fs mv is going to fall back to
> a recursive copy, which:
>  - races with anything using /var/run
>  - breaks named pipes and sockets[0]
>  - other badness (I'll assume there's more than immediately comes to mind ;)

The copying fallback also break any open files.

> [0] mv unlinks then mknods fifos and sockets, but cannot restore a link from the
>     new inode to any processes which already have an fd open
>
> I'm assuming this is the degenerate fallback case when you can't use mount --bind,
> but I think we can still do better. Why not "ln /var/run /run" in this case and
> switch the symlink and actual location after the next "boot"?
>
> If some guest environments skip all of rcS then I'd hope they make some other
> provisions for "at boot" cleanup and other tasks. Otherwise the best we can do
> is document these changes in the release notes as something the local admin
> needs to take care of.

This was specifically about vserver testing where rcS scripts aren't
executed. We are indeed in a fallback case, one where we can't use boot
scripts.

MfG
        Goswin