Re: Request for testing: /run and initscripts
On Fri, 15 Apr 2011, Roger Leigh wrote:
On Fri, Apr 15, 2011 at 01:38:34PM +0100, Edward Allcutt wrote:
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.
In the case described, with a writable / and no tmpfs, what is the downside
to my suggestion? /run would remain linked to /var/run forevermore[0] if
the boottime switcheroo does not happen, but that doesn't seem so terrible.
Both /run and /var/run will remain writable and effectively the same location,
which points to the other isn't terribly important in the short term.
[0] or until the admin prods it as specified in the release notes.
The assumption is that there won't be anything running having open files
in /var/(run|lock)
I think that's an assumption that will fail in some cases and since we can
avoid it we should do so. I have run things like databases and asterisk
in chroots and would vastly prefer running upgrades to not be broken.
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.
Copying the contents is the main thing I'm objecting to. I'm proposing creating
symlinks which do allow a transparent transition and leaving it to the admin to
switch the links around at a convenient time if rc scripts are skipped.
I agree that unusual custom chroot environments can't always be handled fully
automatically. Where I disagree is whether we should make assumptions which
would break running systems rather than simply giving the admin the details
needed to adapt the custom environment at a time convenient to them.[1]
[1] I'm going to guess we'll assume they've taken care of such things
before upgrading to wheezy+1. That seems like a much looser and
safer assumption.
Thank you very much for your time and effort on moving to /run in Debian.
--
Edward Allcutt
Reply to: