[Zope-dev] Re: Possible Windows Service improvements.

[Tres Seaver]

Mark Hammond wrote:
>>Would a lockfile work ok to signify "running" state?  IOW, Zope would
>>lock a file as one of the last steps during startup (which it actually
>>does now, but might do it a bit too early).  The Windows
>>service manager
>>would attempt to lock the same file after <timeout> seconds (although
>>I'm not sure where to get <timeout> from) on initial startup.
> 
> 
>>If the file doesn't exist or the lock succeeds, the process is
>>nonrestartable.
>>If it exists and cannot be locked (Zope has locked it, signifying
>>successful startup), the process is restartable.
> 
> 
> This lets the parent know of successful startup, but doesn't help it during
> the 'starting' phase (if the lock never gets set, how long do we wait before
> giving up?)  Ditto for shutdown - after requesting the child shutdown, how
> long do we wait for it to terminate?
> 
> A single timeout leaves us where we started - it is too fragile to assume
> that if the app has not started after x seconds, it never will.  By having
> the child actively report progress, the parent process can be more confident
> it is alive and normal, even if it is taking a very long time to start.
> 
> Wouldn't a socket work?  As the parent process is starting the child, it
> could pass the port on the cmdline.
> 
> I think by *describing* the API, I made it sound more complicated than it
> is.  It consists of 2 functions:
> 
> def reportState(state, timeout, error_info = None):
>       """Called by the child process, and implemented by the parent.
>          Reports the status of the child process to the parent.
> 
>          state may be 'starting', 'running', 'stopping', 'stopped',
>          'pausing' or 'paused'.
> 
>          timeout is how long before the parent will consider us dead
>          if we don't report progress again.
> 
>          error_info may be specified as the program reports 'stopped'.
>          If None, the shutdown was normal.
>       """
> 
> # This second one is optional, but abstracts away using signals :)
> def changeState(new_state):
>       """Called by the parent process, and implemented by the child.
>          Requests that the client process enter the specified state.
>          Only 'running', 'stopped' and 'paused' are valid (ie, the
>          parent must never request any of the transition states)
>       """
> 
> If we ignore the second and stick to signals, it seems fairly robust and
> achievable.
> 
> The other option is that we get rid of the 'parent' service all together.
> Just have the service code use run.py directly, and run it in-process.  The
> Windows builtin 'auto-restart' facilities for services can handle the
> bizarre errors, and offers the benefit of allowing the user to define the
> restart policy (even allowing them to reboot should it go down <wink>).
> There may be good reasons for that though.

I still think we should look at making a Windwos version of the 
'zdaemon' handler, which uses a Unix-domain socket between parent and 
child:  we could either use a named pipe on Windows, or else a socket on 
localhost, to achieve the same ends.

This would have the upside that 'zopectl' would work the same way on 
windows, as well, which would be a boon for WIndows-based developers.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com