<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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.<br><br>Sent from my iPhone</div><div><br>On Jul 31, 2017, at 00:06, Tom Most <<a href="mailto:twm@freecog.net">twm@freecog.net</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p>Replies inline below.<br>
</p>
On 07/30/2017 10:35 PM, Zack Zatkin-Gold wrote:<br>
<blockquote type="cite" cite="mid:20170731053530.55FE3226271@zk.gd">
<pre wrap="">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".</pre>
</blockquote>
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.<br>
<blockquote type="cite" cite="mid:20170731053530.55FE3226271@zk.gd">
<pre wrap="">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?
</pre>
</blockquote>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
---Tom<br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>talk mailing list</span><br><span><a href="mailto:talk@nblug.org">talk@nblug.org</a></span><br><span><a href="http://nblug.org/cgi-bin/mailman/listinfo/talk">http://nblug.org/cgi-bin/mailman/listinfo/talk</a></span><br></div></blockquote></body></html>