Introducing /run

Posted Mar 30, 2011 14:23 UTC (Wed) by rriggs (guest, #11598)
Parent article: Introducing /run

Sounds like both FHS & LSB need to be updated. Any idea when this would happen?

to post comments

Introducing /run

Posted Mar 30, 2011 14:39 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

FHS hasn't been updated in a long time. However a request has been opened at

http://bugs.freestandards.org/show_bug.cgi?id=718

I completely expect nothing to be done about it.

Fixed link

Posted Oct 19, 2014 1:22 UTC (Sun) by JesseW (subscriber, #41816) [Link] (1 responses)

The LF moved this, and broke the links -- it's now at: https://bugs.linuxfoundation.org/show_bug.cgi?id=718 . The bug is still in ASSIGNED state, with 19 comments, the most recent of which was on 2011-08-23.

Fixed link

Posted Oct 19, 2014 2:01 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

I am disappointed but completely unsurprised to hear my prediction come true.

Introducing /run

Posted Mar 30, 2011 15:05 UTC (Wed) by rleigh (guest, #14622) [Link] (8 responses)

Sounds like a good plan. I don't see why there should be any fear of controversy here--it's a standard replacement for the various ad hoc methods that were already in place. I was an early proponent and adopter of /lib/init/rw (replacing buggy use of /dev/shm as the tmpfs of choice for resolvconf), and /run will be a good replacement, which also cleans up the use of transient files stored under /var.

Reading the thread, there seemed to be good consensus on the need for /run, with one vocal individual disagreeing; however, the disagreement did not appear to address the fact that the existing FHS does not address the need for /run, and that standards are built on consensus, not set in stone. I'm sure that /run could be added to the FHS following its introduction. The FHS has not always established existing practice though--I'm still waiting for /libexec which both the BSDs and GNU coding standards have long supported, and it's a rather glaring incompatibility.

One thing I was going to mention was that LVM will no longer need to keep its cache files under /etc, which was a long-standing flaw in it, making a read-only rootfs easier to achieve. I subsequently found Alasdair Kergon's comments in the thread, which were nice to see. We could also get rid of /etc/mtab as well, without the need for a symlink to /proc/mounts before mount(8) is fully capable of operating without a writable mtab.

Is anyone working on supporting /run in Debian, and replacing /lib/init/rw?

Regards,
Roger

Introducing /run

Posted Mar 30, 2011 15:25 UTC (Wed) by mezcalero (subscriber, #45103) [Link] (7 responses)

/etc/mtab is a symlink to /proc/self/mounts on F15. That problem is solved.

Lennart

Introducing /run

Posted Mar 30, 2011 15:37 UTC (Wed) by rvfh (guest, #31018) [Link] (1 responses)

You mean my dream of a read-only / including /etc could soon become reality?
I believe it's one of your goals too, isn't it?

Good job.

Introducing /run

Posted Mar 30, 2011 16:17 UTC (Wed) by mezcalero (subscriber, #45103) [Link]

Yes, and we are almost there.

Lennart

Introducing /run

Posted Mar 30, 2011 16:26 UTC (Wed) by rleigh (guest, #14622) [Link] (2 responses)

From my discussions with the mount maintainer, this is only completely solved if you're using systemd. For others, it's still broken in some cases, such as read-only bind mounts and NFS mounts:

http://article.gmane.org/gmane.linux.utilities.util-linux...
http://thread.gmane.org/gmane.linux.utilities.util-linux-...

Until Debian adopts systemd exclusively, we are still going to need the above issues fixing before making mtab a symlink. While I would like to see systemd adopted in Debian, I think support for non-Linux kernels is a potential blocker here, mainly for kfreebsd, and Hurd to a lesser extent, if we are to have a unified init across all supported kernels. Not that any of that is my call, just a consideration to bear in mind. It is also likely that Debian will allow other inits such as upstart, which will also require util-linux-ng and related tools to support the above as well.

Regards,
Roger

Introducing /run

Posted Mar 30, 2011 18:49 UTC (Wed) by cmorgan (guest, #71980) [Link] (1 responses)

Support for other non-linux platforms is nice but many of these other non-linux platforms aren't the fastest moving or end up rejecting things done in linux because they aren't done The Right Way(tm).

Introducing /run

Posted Mar 31, 2011 14:21 UTC (Thu) by nye (subscriber, #51576) [Link]

>Support for other non-linux platforms is nice but many of these other non-linux platforms aren't the fastest moving or end up rejecting things done in linux because they aren't done The Right Way(tm).

Note that the GP did not say 'platforms', but 'kernels', which is an important distinction in this context.

Introducing /run

Posted Mar 31, 2011 4:49 UTC (Thu) by ebiederm (subscriber, #35028) [Link] (1 responses)

On f14 /etc/mtab does not handle bind mounts properly when it is a symlink to /proc/mounts. Has that been fixed?

Introducing /run

Posted Mar 31, 2011 9:38 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

Yes, a new version of util-linux fixes that and the change is upstream.