[Zope-dev] Possible Windows Service improvements.

[Mark Hammond]

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

Mark.