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

[Tom Most]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nblug.org/pipermail/talk/attachments/20170731/52df205f/attachment.html>