Re: /run vs /var/run (was: Please test new sysvinit)
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.
> 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?
> [...] 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.
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