note proceng <blockquote>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.</blockquote> 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 <strike>many</strike>some 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: <blockquote>System requirements daemontools works only under UNIX.</blockquote> 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. 841112 841182