The wisdom of having your daemons daemonize themselves is debatable. I think it's better, for a variety of reasons, to run them from a supervisor which can handle things like logging and signal handling.
"Under SVR4, some people recommend calling fork again at this point and having the parent terminate. The second child continues as the daemon. This guarantees that the daemon is not a session leader, which prevents it from acquiring a controlling terminal under the SVR4 rules. [...]"
(That's from p417 in my first edition copy of Stevens. The page number and/or the text may be different in the second edition.)
Something that bugs me about Python is that code like this is distributed on random blogs instead of on some central repository like the CPAN. It's a shame to make people cut-n-paste code into their applications.
Also, I'm conflicted on whether or not I would want to globally change the behavior of a process in a class. setsid, "close STDIN", etc. affect the entire process, not just an instance of the class.
There's no reason you can't do this 'classless' in Python.
I've seen similar Python code that takes the Perl approach, as well as code where the 'daemonizer' is a function that takes a function (which is the main event loop of the daemon) as an argument.
In this case it's a design, not a language decision.
The class is using /tmp for PID files. This will break your service on power outages or kernel crashes, as when your service is starting they won't be able to tell they weren't properly stopped, as all files in /tmp are cleared on reboot.
/var/tmp is the appropriate location for PID files.
