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

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
race problems.

> 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:

Thomas Hood

Reply to: