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

[Zack Zatkin-Gold]

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".

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?

All the best,
Zack
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://nblug.org/pipermail/talk/attachments/20170730/694899eb/attachment.sig>