LinuxQuestions.org - [SOLVED] Separate /run and /var/run

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Separate /run and /var/run (https://www.linuxquestions.org/questions/slackware-14/separate-run-and-var-run-4175524722/)

Separate /run and /var/run

I vaguely remember when /run was first instituted. I seem to remember that there were various breakages due to the changes at the time. I was running Debian at that time and haven't turned up any old discussions about it for Slackware for that time period (spring/summer 2011). It came to my attention recently that /var/run and /run on Slackware64-14.1 system are separate directories. I have been researching this via web search, the FHS 2.3 and 3.0, as well as comparing how other distros handle /run and /var/run.

This is the Debian policy: https: //www.debian.org/doc/debian-policy/ch-opersys.html#s9.1
This is Arch's current PKGBUILD for base filesystem: https://projects.archlinux.org/svnto...ges/filesystem
Gentoo has this bug report: https://bugs.gentoo.org/show_bug.cgi?id=361349
Crux uses separate directories: http://crux.nu/gitweb/?p=ports/core....d28b66;hb=HEAD

I'm still in the process of looking at Suse, Fedora, and Ubuntu and perhaps others.
I've searched the Slackware forum for this and so far haven't turned up anything.

I've read the relevant part of the newer FHS (3.0); it describes /var/run as a link to /run. One issue I can forsee with /var/run being a link to /run is that there may be (probably are) necessary subdirectories that need to exist in the runstate hierarchy.

One thing I'm not trying to do is make a judgement call here on what is correct handling of /run and /var/run. I merely would like some discussion about the topic and try to understand possible impact and ramifications if /var/run were a symlink to /run.

Well, so that all readers know what this is about, here is a quote from the FHS 3.0 Draft 1

Code:

3.15. /run : Run-time variable data



3.15.1. Purpose



This directory contains system information data describing the system since it

was booted. Files under this directory must be cleared (removed or truncated as

appropriate) at the beginning of the boot process.



The purposes of this directory were once served by /var/run. In general,

programs may continue to use /var/run to fulfill the requirements set out for /

run for the purposes of backwards compatibility. Programs which have migrated

to use /run should cease their usage of /var/run, except as noted in the

section on /var/run.



Programs may have a subdirectory of /run; this is encouraged for programs that

use more than one run-time file. Users may also have a subdirectory of /run,

although care must be taken to appropriately limit access rights to prevent

unauthorized use of /run itself and other subdirectories. ^[18]



3.15.2. Requirements



Process identifier (PID) files, which were originally placed in /etc, must be

placed in /run. The naming convention for PID files is <program-name>.pid. For

example, the crond PID file is named /run/crond.pid.



The internal format of PID files remains unchanged. The file must consist of

the process identifier in ASCII-encoded decimal, followed by a newline

character. For example, if crond was process number 25, /run/crond.pid would

contain three characters: two, five, and newline.



Programs that read PID files should be somewhat flexible in what they accept;

i.e., they should ignore extra whitespace, leading zeroes, absence of the

trailing newline, or additional lines in the PID file. Programs that create PID

files should use the simple specification located in the above paragraph.



System programs that maintain transient UNIX-domain sockets must place them in

this directory or an appropriate subdirectory as outlined above.



...



5.13. /var/run : Run-time variable data



5.13.1. Purpose



This directory was once intended for system information data describing the

system since it was booted. These functions have been moved to /run; this

directory exists to ensure compatibility with systems and software using an

older version of this specification.



5.13.2. Requirements



In general, the requirements for /run shall also apply to /var/run. It is valid

to implement /var/run as a symlink to /run.



The utmp file, which stores information about who is currently using the

system, is located in this directory.



Programs should not access both /var/run and /run directly, except to access /

var/run/utmp. ^[46]

More information is available from this web page.

Now here is my input in the discussion.

I don't see an urgent need for that change: if ain't broke, don't fix it.
We are not in a hurry. This document states: "Our goal is to release FHS 3.0 by July 1 if possible." But it bears the date April 27, 2011 ;)
In my opinion, a better place for this discussion would be the fhs-discuss mailing list, although there's not a lot of traffic there.
I don't really care. Anyway Pat will request comments before making a decision, only if he thinks he needs advices or opinions of the crowd. Looking at my crystal ball, I don't see that coming soon.

PS You wrote:

Quote:

I've read the relevant part of the newer FHS (3.0); it describes /var/run as a link to /run.

Actually the draft says:

Quote:

It is valid to implement /var/run as a symlink to /run.

Thus this symlink is allowed but not mandatory.

Oh and even if most other distributions make that symlink that doesn't imply that Slackware neither should nor will do the same. That is true also for the whole /run thing.

Thank you, Didier. I appreciate and respect your input. Thank you for clarifying/reiterating the point about the validity of /var/run as a symlink /run, but not requiring it; sometimes my thinking needs a bit of the hammer before things sink in. I will consider your suggestion about using the fhs-discuss mailing list. An important point to me, though, is that I am more curious about the view of this from a Slackware perspective. I am not saying that the current handling of /run and /var/run in Slackware is wrong, only that I would like more insight. Also, I would venture to guess that the BDFL is much more knowledgeable than I am for what works best for Slackware in this and most cases.

One last thing. I don't think there necessarily needs to be any action on this at all. You bring in a very valid point... "if it ain't broke, don't fix it." Perhaps it is only my understanding is all that needs a little tweaking. You have helped some with that.

Cheers,
John

Quote:

Originally Posted by j_v (Post 5266347)

One thing I'm not trying to do is make a judgement call here on what is correct handling of /run and /var/run. I merely would like some discussion about the topic and try to understand possible impact and ramifications if /var/run were a symlink to /run.

I dislike the idea of symlinking /var/run to /run. Doing so would seem to place arbitrary limitations on how sysadmins can set up their systems.

For example, I might have a service that copies a database to /var/run/ (this permits me to make changes to the off-line db without changing the publc website). I would not want to have that database stored on my root partition because 1) it might potentially be a very large file/directory and 2) my root partition potentially might have rather slow write access (but good read access).

Granted my approach is rather non-standard, and its mainly beneficial for developing my service. Nonetheless, it works for me and I should not like for my use case to be dismissed without good reason, and I do not see any advantage to using a symlink over just having the two directories.

Quote:

Originally Posted by saulgoode (Post 5266476)

For example, I might have a service that copies a database to /var/run/ (this permits me to make changes to the off-line db without changing the publc website). I would not want to have that database stored on my root partition because 1) it might potentially be a very large file/directory and 2) my root partition potentially might have rather slow write access (but good read access).

By default Slackware mounts /run as type tmpfs so unless you change that then there shouldn't be an issue with storing anything on the root partition (there may however be an issue if you don't have enough RAM for whatever you're putting in /var/run, but in that case I think you're better off using /var/tmp or a dedicated directory under /var).

Quote:

Originally Posted by T3slider (Post 5266486)

I'm not seeing /run being a mount point (14.1). I don't have -current installed at the moment, so maybe that is your reference?

The nice feature that /var/run offers compared to /var/tmp is that it gets wiped during reboot.

To be clear, I think /run is a good idea (and Slackware puts it to good use), but symlinking /var/run places unnecessary restrictions upon certain uses.

Thanks, saulgoode. I'm glad to hear your points. I think that your use case is a strong point against the symlinking /var/run to /run. I can see another one, especially given your senario: /run is mounted with a tmpfs, so storing large databases there could be problematic for memory usage as well (ah, I see T3slider beat me to that point).
Ok, got me reading the fhs section on /run once again and I can't believe that this part didn't sink in well enough:

Quote:

The purposes of this directory were once served by /var/run. In general, programs may continue to use /var/run to fulfill the requirements set out for /run for the purposes of backwards compatibility. Programs which have migrated to use /run should cease their usage of /var/run, except as noted in the section on /var/run.

So really, I see that this whole topic is answered for me... it stemmed from my own confusion.
My two cents is that /var/run and /run being separate is a good setup, specifically to maintain backwards compatibility.
Thanks to Didier, saulgoode and T3slider for having a look at my query and the patience to give it some consideration and reply.

Cheers,
John

PS, saulgoode, just to clarify, /run is mounted in /etc/rc.d/rc.S on line 26...

Quote:

Originally Posted by saulgoode (Post 5266494)

I'm not seeing /run being a mount point (14.1).

Quote:

Originally Posted by j_v (Post 5266498)

PS, saulgoode, just to clarify, /run is mounted in /etc/rc.d/rc.S on line 26...

Yes, try

Code:

cat /proc/mounts

which gets the actual mounted partitions. If you just do

Code:

mount

it will only show partitions listed in /etc/mtab, and if you read through /etc/rc.d/rc.S you can see that /run is mounted early on, mtab removed later, and important filesystems 'fake' (re)-mounted to add entries to /etc/mtab. In some distros /etc/mtab is just a symlink to /proc/mounts to synchronize them but I think Pat uses this setup to minimize noise in 'mount' output (only showing important/relevant partitions).

[/off-topic]

Quote:

Originally Posted by T3slider (Post 5266512)

In some distros /etc/mtab is just a symlink to /proc/mounts to synchronize them but I think Pat uses this setup to minimize noise in 'mount' output (only showing important/relevant partitions).

Yes, I can remember having a discussion in email with him about devtmpfs not being in there, and that was the rationale he gave.

On the subject of symlinking mtab -> /proc/mounts, I really don't like that idea. I've noticed a behavioural difference between /proc/mounts and /etc/mtab: specifically, /proc/mounts appears to get updated on an unmount long before /etc/mtab is. My assumption is that /proc/mounts is updated at the start of the unmount operation when the filesystem is detached from the hierarchy -- presumably to prevent anything new from accessing it -- where as /etc/mtab is updated when everything is flushed and the unmount completes. It's particularly noticeable with slow media such as a flash drive.

As I use autofs for the mounting/unmount of flash media, I rely on /etc/mtab to know whether I can safely unplug my device; unlike running a unmount command directly, I don't get confirmation the unmount has completed doing it the way I do ('pkill -USR1 automountd' bound to a hot-key).

Thank you all for setting me straight on the /run tmpfs situation. As I am currently running my server on an old Pentium with only 384MB of memory (with thoughts of eventually switching to a BeagleBone or somesuch), this makes avoiding large files in /run even more important (though my server is still on Slackware 14.0, so /run isn't yet an option).

I am enlightened. :)