[Python-ideas] Draft PEP: Standard daemon process library

Stephen J. Turnbull stephen at xemacs.org
Fri Jan 30 06:20:30 CET 2009


Ben Finney writes:

 > [C]ompare the latest version of this PEP [...].

I'm assuming the one posted on 1/29 in
<87iqnywsx2.fsf at benfinney.id.au>, or fairly close to that.

 > This might because the PEP isn't communicating very well. Does the
 > section "A daemon is not a service" help to explain the fundamental
 > difference between the model suggested by Trent, versus the model in
 > the PEP?

That is quite clear, and you've said "daemonize-me != start-a-
service" in discussion here.  However, you've also said that "daemon
!= service" (including in the title of that section!), which clearly
is mostly false when those terms are referring to the processes that
are running in the background.

I think that focusing on the distinction between "*becoming* a daemon"
and "*starting* a service" is distracting.  The point being that
*becoming* a well-behaved service surely requires becoming a well-
behaved background process.  The real issue is not starting a separate
process (just don't provide a way to do it), but rather it is that it
also requires all the communication setup as well, which is out-of-
scope for a daemonization PEP on any platform (apart from closing file
descriptors, which is specific to the fork(2) implementation of
process creation).  To prevent the misinterpretation I made, I would
phrase that title "A Service is Not Just a Daemon", implying "this PEP
is not a full-service PEP".<wink>

BTW, IMO you can delete the sentence "It is the opinion of this PEP's
author that combining the two disparate systems of behaviour under a
single API would be contrary to the focus of this PEP." from the PEP.
It's redundant.

 > Meanwhile, I and others have a need for a simple, standardised,
 > one-obvious-way "daemonise the current program" library, *entirely
 > distinct from* any of ther extra baggage that comes with a "spawn a
 > separate process that I can then communicate with through channels"
 > API. I intend to satisfy that with this PEP.

Well, that's what I thought was in question here.  It seems to me that
there are likely to be additional aspects to "daemonize me" for Mac OS
X and Windows, but that the basic start-reload-stop methods should
probably apply.  I'm not familiar enough with the process of
daemonization on Mac OS X (Bill mentioned interaction with launchd) or
Windows to help at reasonable expense, but I certainly hope that those
who are will review to see if a similar API might be useful to them.
Unfortunately there doesn't seem to be that much common ground among
the advocates, though.

Steve



More information about the Python-ideas mailing list