Re: /run vs /var/run (was: Please test new sysvinit)
(OK, this time reformatted to make my webmail composer happy.)
Marco d'Itri wrote:
> I do not remember a consensus about this.
Perhaps the last hold-outs can be convinced this time? :)
Bernd Eckenfels wrote:
> and if it is placed in a tmpfs (which is really the best thing
> anyway) it doesnt matter under which mountpoint it is located.
It does matter, because /run needs to be usable before other
filesystems are mounted, and a filesystem can get mounted on /var,
thus hiding anything that was stored at /var/run prior to this.
One might propose shifting things around, but this quickly gets into
> And then it is much cleaner to have only one.
Peter Samuelson wrote:
> Given the need, and now the reality, of /run, is there any need for
> a separate /var/run?
"Need" is probably too strong, but it's certainly convenient if we
don't have to change the way we currently use /var/run/.
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. 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. 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.
Matthew Garrett wrote:
> Under Linux, can't all of this be done with mount --move anyway?
> I'm not convinced that we actually need a /run any more.
The /run approach is simple and robust. Other approaches that have
been proposed introduce some sort of race possibility, dealing with
which makes those approaches more complex than the /run approach.
I am sure that something could be worked out on the basis of
mount --move, but I can't see why we should go to that trouble when
we have a simpler alternative.
Matthew Garrett wrote:
> Has anyone talked to the FHS guys about this?
Yes, I have talked to them about it and there is no objection.
I think I have read all the discussions of this issue in the
archives and I have yet to hear any strong reason why we should
_not_ implement /run. I do not count "It's ugly!" as a strong
Background information at: