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 transparent. > [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. Regards, Roger -- .''`. 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.
signature.asc
Description: Digital signature
