LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 11-07-2014, 03:20 PM   #1
j_v
Member
 
Registered: Oct 2011
Distribution: Slackware64
Posts: 364

Rep: Reputation: 67
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.
 
Old 11-07-2014, 04:15 PM   #2
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1 on Lenovo Thinkpad W520
Posts: 8,749

Rep: Reputation: Disabled
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.

Last edited by Didier Spaier; 11-07-2014 at 11:24 PM. Reason: PS added.
 
2 members found this post helpful.
Old 11-07-2014, 07:40 PM   #3
j_v
Member
 
Registered: Oct 2011
Distribution: Slackware64
Posts: 364

Original Poster
Rep: Reputation: 67
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
 
Old 11-07-2014, 09:09 PM   #4
saulgoode
Member
 
Registered: May 2007
Distribution: Slackware
Posts: 288

Rep: Reputation: 155Reputation: 155
Quote:
Originally Posted by j_v View Post
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.
 
1 members found this post helpful.
Old 11-07-2014, 09:53 PM   #5
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,367

Rep: Reputation: 838Reputation: 838Reputation: 838Reputation: 838Reputation: 838Reputation: 838Reputation: 838
Quote:
Originally Posted by saulgoode View Post
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).
 
1 members found this post helpful.
Old 11-07-2014, 10:12 PM   #6
saulgoode
Member
 
Registered: May 2007
Distribution: Slackware
Posts: 288

Rep: Reputation: 155Reputation: 155
Quote:
Originally Posted by T3slider View Post
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).
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.
 
Old 11-07-2014, 10:31 PM   #7
j_v
Member
 
Registered: Oct 2011
Distribution: Slackware64
Posts: 364

Original Poster
Rep: Reputation: 67
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...

Last edited by j_v; 11-07-2014 at 10:33 PM.
 
Old 11-07-2014, 11:52 PM   #8
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,367

Rep: Reputation: 838Reputation: 838Reputation: 838Reputation: 838Reputation: 838Reputation: 838Reputation: 838
Quote:
Originally Posted by saulgoode View Post
I'm not seeing /run being a mount point (14.1).
Quote:
Originally Posted by j_v View Post
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]
 
1 members found this post helpful.
Old 11-08-2014, 05:14 AM   #9
GazL
Senior Member
 
Registered: May 2008
Posts: 4,948
Blog Entries: 15

Rep: Reputation: 2524Reputation: 2524Reputation: 2524Reputation: 2524Reputation: 2524Reputation: 2524Reputation: 2524Reputation: 2524Reputation: 2524Reputation: 2524Reputation: 2524
Quote:
Originally Posted by T3slider View Post
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).

Last edited by GazL; 11-08-2014 at 05:15 AM.
 
1 members found this post helpful.
Old 11-08-2014, 11:45 AM   #10
saulgoode
Member
 
Registered: May 2007
Distribution: Slackware
Posts: 288

Rep: Reputation: 155Reputation: 155
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
/var/log/wtmp vs. /var/run/utmp masenko703 Linux - Newbie 4 10-05-2012 03:41 AM
How to run kernel functions in a separate core? reksss Ubuntu 4 10-03-2012 10:24 AM
sshd trojan? keys / passwds written in /var/run.defunct, /etc/httpd/run/.defunct raymor Linux - Security 8 08-11-2011 11:25 AM
Run 2 NICs, separate networks liche24 Fedora 1 03-14-2009 11:20 PM
rm cannot remove /var/run/atd.pid and /var/run/xdm.pid danishmr Linux - Software 1 05-04-2004 08:01 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 08:49 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration