[Python-ideas] Draft PEP: Standard daemon process library
python-ideas-list at trentnelson.com
Wed Jan 28 04:03:53 CET 2009
On Wed, Jan 28, 2009 at 01:15:41PM +1100, Ben Finney wrote:
> Trent Nelson writes:
> > On Wed, Jan 28, 2009 at 08:18:51AM +1100, Ben Finney wrote:
> > > Jesse Noller writes:
> > >
> > > > I think adding the windows services functionality distracts from
> > > > the reasonable goal of the PEP Ben is proposing.
> > >
> > > Thanks, this is my position also.
> > I disagree. Partly because I'm in a bit of a devil's advocate mood
> > at the moment. But mostly because I know what will happen: [???]
> I respectfully suggest that this isn't true, because your hypothetical
> situation continues:
> > After poking around the source, I'm perplexed. It's not doing
> > anything uniquely Unix-xy,
> Your disagreement seems to rest on this assertion, and I don't see how
> your hypothetical described can be true. Do you really see the
> described behaviour in the current draft PEP as ???not doing anything
> uniquely Unix-y????
No, the PEP is nothing but Unix-isms, that's my point. The 3rd
party code I'm hypothetically wading through has been coded to
that interface, but semantically, it's not doing anything unique
> :Default: ``True``
> If true, prevents the generation of core files, in order to
> avoid leaking sensitive information from daemons run as `root`.
I was going to suggest service.set_secure(True); but then I wondered
what is this actually achieving? Won't the resulting .core will be
owned by root?
> :Default: ``'/var/run'``
> Absolute directory path to contain the daemon's lockfile. If
> ``None``, the lockfile behaviour for this daemon is skipped.
> :Default: ``None``
> Base name of the lockfile for this daemon, without directory or
> suffix. If ``None``, the name is derived from the process command
All you're doing is ensuring multiple instances of the daemon don't
run. On Windows, you'd use a mutex, on Unix, sure, lockfile makes
sense. A cross-platform interface wouldn't bother exposing this
> > just your normal, run-of-the-mill start/stop type stuff.
> As far as I can tell, beyond trivial use cases, there is both wide
> discrepancy and very little overlap in ???start/stop type stuff???
> between a Unix daemon and an MS Windows service. At least, none of the
> (admittedly few) instructions on MS Windows services I've seen
> demonstrate otherwise.
Semantically the overlap is almost identical, which is why I'm
interested in hearing why the QtService-type approach couldn't
be leveraged here. (The implementation details differ wildly,
which is what you're referring to.)
> Someone who thinks otherwise is welcome to attempt a PEP that brings
> all that behaviour under a single banner *and* design the API to be
> both flexible enough to be useful in many use cases and simple enough
> to be worth learning instead of doing it manually. That person will
> not be me.
EventType = namedtuple(
Success = 1,
Error = 2,
Warning = 3,
Information = 4,
StartupType = namedtuple(
Auto = 0,
Manual = 1
def __init__(self, name, desc=None, startup_type=StartupType.Auto)
self.name = name
self.description = desc
def parse_arguments(args): pass
def is_running(self): pass
def is_installed(self): pass
def install(self): pass
def uninstall(self): pass
def report_event(self, msg, event_type, id, category, data): pass
def exec(args): pass
def terminate(): pass
def request_pause(): pass
def request_resume(): pass
def send_command(code): pass
def run(args): raise NotImplementedError()
def start(): pass
def stop(): pass
def pause(): pass
def resume(): pass
More information about the Python-ideas