[NBLUG/talk] Why have directories in /var/run if they're not persistent through reboot?

Zack Zatkin-Gold zg at zk.gd
Mon Jul 31 00:36:21 PDT 2017


It's not so much about creating the directory that is the issue.  If I use Puppet to orchestrate a server's provisioning, thus ensuring that the directory exists, Puppet doesn't run when the server reboots, therefore the directory doesn't get created.  It is likely a side effect of deviating from application defaults, i.e. not letting a particular application handle PID file creation on its own.

Sent from my iPhone

> On Jul 31, 2017, at 00:06, Tom Most <twm at freecog.net> wrote:
> 
> Replies inline below.
>> On 07/30/2017 10:35 PM, Zack Zatkin-Gold wrote:
>> Hello NBLUGers,
>> 
>> I'm curious what your thoughts are on what appears to be a bad pattern
>> on Linux (and potentially UNIX-based programs, too?).
>> 
>> When a UNIX-based program gets daemonized, it typically will create
>> what is known as a PID file under the /var/run folder.  The contents
>> of this file contains the process ID corresponding to the current
>> running daemon for that program.  For example, if dnsmasq is running
>> and the process ID is 1234, then /var/run/dnsmasq.pid is simply a
>> text-based file containing "1234".
> I'll take a moment to node that pidfiles are not usually necessary on a modern Linux system: under systemd there is no need to bother with them, as init tracks the process directly.
>> What appears to be a bad pattern is that some programs will *create a
>> directory* within /var/run, and then create a pid file under that
>> directory to identify the process ID it is running under.  By default,
>> /var/run is configured in fstab as tmpfs which is a temporary file
>> storage mechanism.  This means that when the system reboots, the
>> contents of /var/run are lost, including all subdirectories.  Anything
>> within the system that looks to the directory created by the program
>> under /var/run will find that it doesn't exist, or even worse, it
>> will attempt to create a pid file under that directory and will be
>> unable to because the directory doesn't exist under /var/run.
>> 
>> Here's a scenario to demonstrate why this is a potentially bad
>> pattern:
>> 1. program foo gets daemonized and stores its PID file in
>>    /var/run/foo/foo.pid
>> 2. program bar monitors /var/run/foo/foo.pid for some reason
>> 3. system reboots; contents of /var/run are lost
>> 4. program bar attempts to monitor /var/run/foo/foo.pid, but cannot
>>    because /var/run/foo does not exist
>> 
>> With all that being said, what is the purpose for creating
>> subdirectories under /var/run if they're known to not persist through
>> reboots?
> I would guess that this pattern comes about because some UNIX systems do not apply filesystem permissions to UNIX socket files.     Thus, to control access to the socket you must create a directory and adjust its ownership and permissions as appropriate. I don't believe that this is a problem on Linux, though (for example /var/run/docker.sock isn't put in a directory, yet it is only accessible to the docker group).
> 
> However, there is another reason to use this pattern: /var/run (or really /run, all hail systemd again) is owned by root and not arbitrarily writable. If a service runs as non-root, it won't be able to create files there at all. A subdirectory can be made writable by whatever user the process runs as.
> 
> I also don't understand the reason for the question: what's so difficult about creating a directory? And why is it a problem to lose a pidfile due to reboot? The pid counter resets anyway, so it seems advantageous to forget about whatever process was running in a previous boot.
> 
> ---Tom
> _______________________________________________
> talk mailing list
> talk at nblug.org
> http://nblug.org/cgi-bin/mailman/listinfo/talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nblug.org/pipermail/talk/attachments/20170731/455a7226/attachment.html>


More information about the talk mailing list