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

[E Frank Ball III]

I agree it's an issue.  I have CentOS 7 machines with the logcheck
package installed and I had to put this kludge into /etc/rc.local:

 mkdir -p /var/lock/logcheck
 chown logcheck:logcheck /var/lock/logcheck
 chmod 1700 logcheck

Package maintainers aren't getting in sync with systemd.

/FrankB

On Mon, Jul 31, 2017 at 12:36:21AM -0700, Zack Zatkin-Gold wrote:
 >    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 <[1]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
 >      [2]talk at nblug.org
 >      [3]http://nblug.org/cgi-bin/mailman/listinfo/talk
 > 
 > References
 > 
 >    Visible links
 >    1. mailto:twm at freecog.net
 >    2. mailto:talk at nblug.org
 >    3. http://nblug.org/cgi-bin/mailman/listinfo/talk

 > _______________________________________________
 > talk mailing list
 > talk at nblug.org
 > http://nblug.org/cgi-bin/mailman/listinfo/talk