

A simple Unix daemon in Python - soundsop
http://www.jejik.com/articles/2007/02/a_simple_unix_linux_daemon_in_python/

======
maw
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.

------
river_styx
Can someone explain why he forks the process twice? The url in the comment
doesn't work.

~~~
maw
"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.)

------
jrockway
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.

I prefer the Perl approach:

<http://search.cpan.org/~ehood/Proc-Daemon-0.03/Daemon.pm>

At least it's clear that the entire process is affected.

~~~
bcostlow
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.

~~~
jrockway
_There's no reason you can't do this 'classless' in Python._

Sure. At that point in my comment, I was no longer comparing languages, and
merely commenting on the implementation of the linked article.

------
nailer
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.

