On Mon, Dec 19, 2005 at 11:41:26AM -0800, Russ Allbery wrote:
> Thomas Hood <jdthood@yahoo.co.uk> writes:
> > Any other defenders of /lib/run? Of /run?
> /run makes much more sense to me. /lib/run just seems unbearably ugly,
> not to mention that it would be kind of nice to have a read-only /lib be a
> possibility for a variety of reasons
/., /bin, /etc, /lib, and /sbin all need to be on the same filesystem (or
at least all mounted by the time init is invoked). There's no practical
difference between expecting /run and /lib/run being writable -- you're
either expecting / to be writable, or you're using it as the mountpoint
for a new writable filesystem. Also, /dev/shm can already be an example
of a rw filesystem mounted on top of a readonly subdirectory on the root
filesystem, eg.
Pros and cons of /run:
+ already implemented
+ name and purpose roughly match /var/run
- new directory in /
- promotes the files it contains from /etc etc into first class
citizens, overstating their importance
- provides a more prominent namespace than /var/run, encouraging misuse
Pros and cons of /lib/var or /lib/run:
+ use of /lib corresponds with use of /usr/lib and /var/lib
+ keeps files out of the way
- have to introduce a separate dir to separate behaviour corresponding
to /var/lib from behaviour corresponding to /usr/lib
Pros and cons of /var/run:
+ requires no software changes, just policy ones
- leaves the burden of ensuring /var is mounted early enough on
Debian users
There aren't any technical differences between the first two options.
Each of the solutions has a degree of ugliness -- in the first case,
the ugliness is in violating the "no new directories in /" rule and
making /run/ifstate seem more important than /etc/network/ifstate or
/var/run/ifstate would be; in the second, it's in having to introduce
a new subdirectory name to separate the variable parts of /lib out; in
the third, it's the system specific ugliness of having to ensure /var
is mounted early.
(TBH, I'd be much happier just making the technical changes necessary
to ensure /var is mounted early -- keeps the filesystem sane, and it's
just a simple matter of programming, rather than arguing over what's
ugly. If you need to use a tmpfs because you can't mount /var without
writing somewhere (to determine drivers, perhaps), it doesn't seem that
unreasonable to setup something like:
/: var/run -> /root/run
mount -t tmpfs tmpfs /root/run
/var: run -> /root/run
Local read-only / and NFS mounted /var might also require something
similar; but leaving the special cases for the systems that need it
seems a more reasonable idea than forcing it on everyone. Also, note
that onion mounts will probably eventually mean all this only needs to
be a temporary hack)
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature