On Wed, May 18, 2011 at 01:57:04PM +0200, Santiago Vila wrote: > > > I feel that we are relying too much on base-files for no particular > > > reason. In fact, I don't see any benefit of having /run in base-files > > > at this point. > > > > The main need for this is debootstrap. There's two possible ways > > initscripts can handle the migration: > > > > 1) Normal system > > - on installation, bind mount /var/run to /run, /var/lock to /run/lock > > - on reboot, set up /run as a tmpfs and convert the original locations > > to symlinks > > 2) Chroot or other virtual environment > > - the above isn't possible (no scripts run on startup etc.) > > - on installation, symlink /run → /var/run and > > /run/lock (/var/run/lock) → /var/lock > > You seem to imply that we should migrate each and every file at once. > > We could just declare /var/run obsolete and not make any bind mount or > symlink. > The use of /var/run then would just fade away over time, like it happened > with the /usr/doc transition.
The issue here is that /var/run is still an FHS-mandated directory, and
while /run supersedes it, both need to be present and hold the same
contents to allow migration. We could do it without the bind mount and
symlinks, but then every package needs to manage migration from
/var/run to /run including moving the pidfiles and other data. With
the bind mount/symlink, this part is completely transparent: programs
simply switch to the new path after wheezy is released, and that's it,
so this saves a lot of effort for individual maintainers, unlike
/usr/doc, which required every package to migrate separately (and this
was files provided in packages, whereas /var/run is only dynamically
created state, which simplifies things as well).
The other issue I have is that the /usr/doc transition took *years*,
and multiple stable releases to finalise. With this transition, we've
taken a lot of effort to ensure that the transition is seamless, and
immediate, to ease migration and allow for a much faster and simpler
transition than /usr/doc.
> AFAIK (please correct me if I'm wrong), this is not like /var/mail
> where email clients look at a single place. Packages putting things in
> /var/run will look for them in /var/run, and packages putting things
> in /run will look for them in /run.
Yes, this is the case. But with the existing migration, the contents
at both locations are identical.
> But even if we want symlinks or bind mounts:
>
> I made a mistake in base-files 2.1.18 when I added /dev/pts (this was
> more than 10 years ago, but there are a lot of similarities). Things
> became too tricky because /dev was a virtual filesystem. I had to
> remove it in 2.1.20 with urgency=high, but since then it is clear to
> me that this kind of things are better handled by whatever package is
> actually populating those directories.
I think I've perhaps explained why base-files needs to provide /run
poorly, so I'll try better. It's fine for this to be done in
initscripts for normal systems, but in chroots it's not so good.
There are four possible upgrade/install paths to consider:
1) squeeze→wheezy upgrade (normal system)
2) squeeze→wheezy upgrade (chroot)
3) clean wheezy install (normal system)
4) clean wheezy install (chroot)
With /run being provided by initscripts, we handle (1) and (3)
just fine. Initially /run is absent, created on initscripts install,
and migration completed after reboot. With (2) we do a best effort
with symlinks, but don't do a very good job: /run is a symlink to
/var/run, so the old directories remain in place (we can't safely move
them). For (4) we really want the new directory structure with
compatibility symlinks, rather than a repeat of (2), or else chroots,
even freshly debootstrapped ones, will never be able to migrate to the
new hierarchy automatically. If this was already set up by base-files,
we wouldn't have a problem, but it's not, so debootstrapping a current
unstable chroot results in the upgrade cludge we use for (2).
These are the specific upgrade/install paths, with and without
/run being provided by base-files. Note I'm only considering
/var/run (/var/lock is treated identically, so I'm omitting it).
In square brackets, I've put the state of /run and /var/run at that
point (→ is a symlink, = is a bind mount).
A) without base-files providing /run directory and /var/run symlink to /run:
1) squeeze→wheezy (normal system)
initscripts adds /run
initscripts bind mounts /var/run on /run
[/var/run=/run]
[reboot]
initscripts mounts tmpfs on /run
initscripts symlinks /var/run symlinked to /run
[/var/run→/run]
2) squeeze→wheezy (chroot)
initscripts adds /run
initscripts removes /run and replaces it with a symlink to /var/run
[/run→/var/run]
3) wheezy install (normal system)
initscripts adds /run
initscripts bind mounts /var/run on /run
[/var/run=/run]
[reboot]
initscripts mounts tmpfs on /run
initscripts symlinks /var/run to /run
[/var/run→/run]
4) wheezy install (chroot)
initscripts adds /run
initscripts removes /run replaces it with a symlink to /var/run
[/run→/var/run]
B) with base-files providing /run directory and /var/run symlink to /run:
1) squeeze→wheezy (normal system)
base-files provides /run
base-files does not provide /var/run but it already exists, so no action
initscripts also provides /run
initscripts bind mounts /var/run on /run
[/var/run=/run]
[reboot]
initscripts mounts tmpfs on /run
initscripts symlinks /var/run to /run
[/var/run→/run]
2) squeeze→wheezy (chroot)
base-files provides /run
base-files does not provide /var/run but it already exists, so no action
initscripts also provides /run
initscripts removes /run and replaces it with a symlink to /var/run
[/run→/var/run]
3) wheezy install (normal system)
base-files provides /run
base-files does not provide /var/run, /var/run does not exist
base-files creates /var/run symlink to /run
initscripts provides /run
[* no tmpfs mounted on /run at this point]
initscripts sees /var/run already symlinked, so no action
[/var/run→/run]
[reboot]
tmpfs mounted on /run
initscripts sees /var/run already symlinked, so no action
[/var/run→/run]
4) wheezy install (chroot)
base-files provides /run
base-files does not provide /var/run, /var/run does not exist
base-files creates /var/run symlink to /run
initscripts also provides /run
initscripts sees /var/run already symlinked, so no action
[/var/run→/run]
So the final states are
A B
1 [/var/run→/run] [/var/run→/run]
2 [/run→/var/run] [/run→/var/run]
3 [/var/run→/run] [/var/run→/run]
4 [/run→/var/run] [/var/run→/run]**
So B4 (**) was fixed by having /run directory and the /var/run symlink
provided by base-files. The only possible bug here is B3, marked with
an asterisk[*]; because this isn't currently possible initscripts
doesn't mount a tmpfs on /run at this point, but if base-files does
provide /run directory and a /var/run symlink, I'll add the mount here
to cater for new wheezy/unstable installs. In fact, I'll add it in the
next upload in any case.
The above B sections assume that base-files:
- provides the /run directory
- does not provide the /var/run directory
- creates the /var/run→/run symlink if /var/run is absent or points to
another location.
/var/lock is slightly different because it points to /run/lock, which
will not exist until /run is mounted. With a recent initscripts, this
will never occur, because /run/lock is created prior to /var being
mounted at boot. base-files can't realistically provide /run/lock as a
fallback since it could be on a tmpfs mount, but the dangling symlink
in practice won't be a problem if base-files
Breaks: initscripts (<< 2.88dsf-13.3)
because this will ensure its presence since it will require a newer
initscripts be installed (or that an alternative such as systemd is
present). If the admin is doing something very non-standard, it might
be a dangling link, but all the supported configurations will use
initscripts.
I hope this makes things a bit clearer. I've tried to consider all of
the supported upgrade and install paths, with and without the base-files
change. Providing base-files has the Breaks: initscripts, I think it
should be safe to make the change--it shouldn't result in the breakage
seen last time /run was introduced now that initscripts supports /run
properly, and udev also copes with /run better as well.
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
