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

Re: /run vs /var/run (was: Please test new sysvinit)

On Sun, Dec 18, 2005 at 01:26:45PM +0100, jdthood@tiscali.nl wrote:

> Steve Langasek wrote:
> > (We also shouldn't need to specify a policy for mounting any
> > particular filesystem on /run, but merely mount /run early iff it's
> > present in /etc/fstab and leave the implementation details to the 
> local
> > admin.)

> I think that packages Depending on initscripts >= 2.86.ds1-7 should be
> entitled to assume that /run/* is a writable location available very 
> early after boot.

Yes, they should.

> Initscripts 2.86.ds1-7 includes /run and mountvirtfs mounts a tmpfs on it,
> thus causing this assumption to be true.  If the local admin wants
> something else then he or she can edit the script in such a way that
> the aforementioned assumption remains true.

No, having to edit init scripts sucks.  So does having mounts that aren't
controlled via /etc/fstab.

Are there really any init scripts that need to write out data prior to
checkroot.sh (the point at which /run would be writeable by default on the
rootfs)?  If not, why can't we mount /run using /etc/fstab as part of
checkroot.sh, and leave the details to the admin?  This optimizes for the
common case, and leaves the way open for solutions to uncommon requirements.

> If there is demand for an alternative standard operation mode that
> satisfies the assumption then that can be implemented, of course, but
> offhand I can't think of why anyone would need anything but the default
> configuration.

The two use cases that were raised when /run was first discussed were:

 - NFS-mounted /var filesystem
 - read-only / filesystem

Having a /run directory for early-boot volatile data addresses the needs of
both of these use cases (even simultaneously -- hurray!), but by
constraining the actual *implementation* of /run (barring ugly hacking of
the init scripts), you've made the system less suitable for a third use

 - memory is at a premium, disk is not

I'm not going to claim that I know of any particular users that are affected
by this change; files that are candidates for /run (or /lib/run) are
typically small enough that it's fairly unlikely for this alone to impact
what they can or can't do with Debian.  But that's also not the point:  the
point is that design-wise, there's simply no reason to make the choice for
the user of *what* is mounted on /run, only to specify that *something* must
be (and that it must be writable); given that the existing default is
perfectly suitable for the majority of users, I believe we're better off not
touching it.

If you really want to be clever though about supporting upgrades for users
that may already have read-only root, I guess you could do something like

if grep -q '[[:space:]]/run' /etc/fstab; then
	mount $options /run
elif grep -q '[[:space:]]/[[:space:]].*\bro\b' /etc/fstab; then
	mount $options -t tmpfs tmpfs /run

And then everyone can be happy. :)

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: