[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Request for testing: /run and initscripts

On Fri, Apr 15, 2011 at 01:38:34PM +0100, Edward Allcutt wrote:
> 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
> 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 ;)

This is correct.  But as mentioned below, this is a fallback, not the
default.  The default bind mount behaviour is race-free and entirely

> [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"?

Your assumption is correct in that this is a fallback.  This is the
special case for chroots, also co-opted for vservers, which don't "boot"
per se, and don't run the rcS scripts.  The consequence of this is that
we can't do any setup at boot time; the chances are that no filesystems
will be mounted at all, and if there are, we don't have any control over
that process.  This means that the migration in postinst is unfortunately
a "best effort"; I'd like to make it more reliable if at all possible.
The assumption is that there won't be anything running having open files
in /var/(run|lock)--unlike for a normal host, we can't do any bind mounts
or other clever stuff, because they'll be lost on restart, and hence the
new paths will never be set up again, causing breakage.

An alternative could be to just copy the contents, but we really do need
the symlinks in place or else programs can't transition to the new paths
transparently as on normal systems.

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

For regular chroot environments, e.g. as used on buildds, sbuild,
schroot, etc., these directories won't normally be used.  If you're
running services inside a chroot environment, you'll need to stop them
prior to upgrading.  This isn't a new requirement though--chroots have
all sorts of limitations such as this, and having a 100% reliable
upgrade path in situations like this is hard to achieve.

As mentioned in another post, the above shell script can probably be
made more reliable on failure, but it's likely that some chroots will
need the admin to move stuff by hand if it fails.


  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment: signature.asc
Description: Digital signature

Reply to: