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

Re: /run vs. /lib/run

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)


Attachment: signature.asc
Description: Digital signature

Reply to: