Ian Bicking: the old part of his blog

Re: Daemon Best Practices

Before daemonizing I see if the pidfile exists, if it does I open it and try to lock it. If my lock succeeds, there is no other process.. I the close the file and continue. After daemonization I then open the pid file and lock it, flush it and keep it open (might be race in there).. This has worked pretty well for me..

I still have the issue of something failing after daemonization.. I've had good luck creating a pipe before daemonizing.. After the fork my parent has the read end and the daemon has the write end.. The daemon then can write to the pipe which is then displayed to stdout and it sends a keyword when it has started successfully at which point the parent can then exit. Its worked pretty well, but can get a little complex.

Comment on Daemon Best Practices


Do you (or anyone else) have an example of doing the piping? Live-but-should-be-dead processes are always really painful to debug ("why don't my code edits change anything?!?"), especially since sometimes tracebacks show the current code, not the code that's actually being run, further bending your mind ("how can I get a NameError for x, when x isn't used on that line?!?").

I have added some stuff from QP that tests if a process is still alive, so it should make these detached and untracked servers a little less common (e.g., by testing that a process is dead before deleting the pidfile, and testing that it's not alive before overwriting the pidfile). That might be enough.

# Ian Bicking