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

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

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 
> it doesnt matter under which mountpoint it is located.

It does matter, because /run needs to be usable before other 
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 
> separate /var/run?

"Need" is probably too strong, but it's certainly convenient if we 
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 
> 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 
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 
wants something else then he or she can edit the script in such a way 
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:
> 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 
I have yet to hear any strong reason why we should _not_ implement 
I do not count "It's ugly!" as a strong reason.

Background information at:

Thomas Hood

Reply to: