Re^3: Proc::PID::File problem generating pid files, or: does it matter where a pid file lives?

[afoken]

1. Check for existence and program access to:
   • PID directory (typically /var/run or /usr/local/var/run)
   • Log file directory
   • Data file directory
   • Other system resources (network ports, specific hardware)
2. Reset user credentials (first reset group ID, then user ID)
3. Create PID file and lock for exclusive access.
4. Open log file(s)
5. Allocate resource(s)

Are you aware that this still has a race condition? You run a lot of tests in step 1, most of those tests involve system calls. Step 2 has two system calls. Each and every system call may cause a task switch to a malicious program that -- with a little bit of luck and good timing -- can change what you checked for in step 1, causing the following steps to fail rather unexpectedly. And each and every system call may cause a task switch to a second instance fighting for the PID file.

Daemons do not need PID files, and most daemons contain code that they don't really need, for backgrounding, logging, restarting, dropping privileges, and to prevent multiple instances. The daemontools reduce code complexity in daemons and they take care of backgrounding, logging, restarting, dropping privileges, and single instances. Even communication via signals works completely without PID files (with a patch, SIGUSR1 and SIGUSR2 can also be sent). Daemontools may look strange, and some of DJBs decisions (errno, location in filesystem, ...) may cause a little bit of confusion, but once you unterstand what happens, the daemontools are the most natural way to implement daemons on Unix and derivates.

Alexander

[proceng]

Are you aware that this still has a race condition? You run a lot of tests in step 1, most of those tests involve system calls. Step 2 has two system calls. Each and every system call may cause a task switch to a malicious program that -- with a little bit of luck and good timing -- can change what you checked for in step 1, causing the following steps to fail rather unexpectedly. And each and every system call may cause a task switch to a second instance fighting for the PID file.

Alexander:
Yes, I am quite aware that there may be a race condition (but also that the condition may be rare). Since many of the steps, by their nature, can not be atomic, that is a chance that is taken. I would rather know before attempting to connect to a database (for example) that it could be in an inconsistent state due to an abnormal termination. While everything may work right, simply knowing about the problem can go a long way to preventing it from happening in the future.

Many of the options (like the daemontools that you note), do the same things that I describe (just masking them from the programmer).
While you are correct that manysome daemons do not need certain functions, that does not mean that they do not have their place. Add to that the fact that packages such as daemontools have their own built in set of limitations:

System requirements
daemontools works only under UNIX.

and that they require an extra installation step to accomplish the same goal, and you can see that it is useful to know what is being done and why.

In my opinion, when you have to adjust to another's decisions (and add complexity at the same time), it is not necessarily a good thing.