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

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

On Mon, Dec 19, 2005 at 12:23:00PM +0100, Thomas Hood wrote:
> Steve Langasek wrote:
> > 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)?

> Well, it would be nice if fsck logs could be stored in /run until
> /var/log/ is available for writing.  It would be nice if mtab could
> be kept in /run so that it could be written to as filesystems are
> being mounted.  Currently these sorts of things are delayed using
> one trick or another.

Ok, that's fair.

> > 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 case:
> >
> > - memory is at a premium, disk is not

> Tmpfs memory can be swapped out, so is this even a hypothetical problem?

Maybe it isn't on Linux.  I wasn't aware tmpfs could be swapped out.

That still leaves the question of just which features we want to require
from our non-Linux kernels for basic operation, I guess.

> > [...] 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);

> One advantage to supporting only tmpfs on /run is that the assumption
> can then be made that the hierarchy is empty at boot; there are no
> stale files and no cleaning has to be done.

Seems to me that we have a handle on the process of cleaning directories by
now though, no? :)

> If there are reasons why some users would not want to put a tmpfs at
> /run (which there may well be, although I haven't heard them yet)
> then we can of course support this.  Then either initscripts will have
> to clean the directory or programs using it will have to contend with
> stale files.  Cleaning cannot occur until the filesystem underlying
> /run is mounted read-write and programs must not use /run before the
> cleaning has been completed; it would probably be easier to drop the
> cleanliness-at-boot guarantee and let programs clean out their own
> stale files.

Sounds to me like this will play havoc with idempotence of init scripts;
anyway, why would "mount /run and clean it" be anything less than an atomic
operation from the viewpoint of other init scripts?

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: