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

[Trent Nelson]

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
    to Unix.

> `prevent_core`
>    :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?  

>`lockfile_directory`
>    :Default: ``'/var/run'``
>
>    Absolute directory path to contain the daemon's lockfile. If
>    ``None``, the lockfile behaviour for this daemon is skipped.
>
>`lockfile_name`
>    :Default: ``None``
>
>    Base name of the lockfile for this daemon, without directory or
>    suffix. If ``None``, the name is derived from the process command
>    line.

    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
    implementation detail.

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

    class Service(object):
        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
        
    }:>


        Trent.