[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