[Zope-dev] Possible Windows Service improvements.

[Jim Fulton]

Mark Hammond wrote:
...
> Thanks Jim.
> 
> I agree with those concerns.  Note that already we "do not recognise startup
> failure and keep retyring even though we shouldn't", and is exactly what I
> am trying to solve.

Yup

> 
>>Is there some sort of IPC that can be used here?  On Unix, we
>>use a reserved
>>exit code to indicate a startup failure and arrange for Zope
>>to exit with that.
> 
> 
> The Unix situation is a little different - if "runzope" itself has immediate
> startup failure, then everything immediately fails - ie, as far as Unix is
> concerned, the "service" itself failed.
> 
> On Windows however, "runzope" is executed as a *child* of the service.  If
> the child fatally fails, the service itself is still reporting success, and
> hopelessly attempting a restart.  The service needs to know if the child
> fatally failed.  This doesn't apply on Unix as "runzope" *is* the 'service',
> not the child of the service.
> 
> By adding a layer around run.py, I believe we could arrange for these fatal
> errors to be handled with a special return code.

I assume by "fatal", you mean errors that we should not try to restart
from.

Let me see if I understand the use cases here:

- Normal shutdown.  (Should it be possible to shut down Zope
   through the web on Windows?)

- Start-up error. We want to log relevent information somewhere.
   We don't want to restart.

- Run-time (after startup) error.  We also want to log a problem,
   but we do want to restart Zope.

Note that we also need to consider uncontrolled exits, like segfaults.

 > Alternatively, if Zope
> itself never returns an error code of 1 (one), then we could use that -
> Python itself returns this for unhandled exceptions.  That seems dangerous
> though.
> 
> Can you offer some advice here?

Probably not at the level you are asking.  I'm not familiar with any of the
details here and can't make the time to be.  I just know we need an explicit
mechanism, rather than trying to guess based on timing.


> * Is an exit-code of 1 suitable for a fatal error? If so, this requires no
> changes to the child process.  However, I assume it is not suitable.

Why not use an exit code of 0?

I think that Zope could arange to exit with an exit code of 0 if there is a
startup error.

> * Is a special exit code, generated by a wrapper to run.py (eg, run_svc.py)
> suitable?  If so, what value do you recommend?

Sorry, I don't understand these scripts will enough to comment.

> * Should some Win32 specific, robust IPC mechanism be investigated?  This
> would cut deeper into a run.py wrapper, and obviously is not a general
> solution.

I think there is a general solution lurking here.  But I'm too ignorant
of the details to be more specific. :(


> 
>>On another note, I'd really prefer to work out a general facility that
>>can be used with any Python program, including both Zope 2 and Zope 3.
> 
> 
> The problem at the moment is that our facilities are *too* general - ie,
> without some coordination between the parent and child, the parent must
> guess. 

Right.  We need something at a lower level.  It would be OK with me
if this something had an API that the program being run had to use.


 > The simplest coordination does seem to be process exit code, but
> that seems fragile. 

Yup.

 > But whatever coodination is chosen, any Python program
> that was willing to play the coordinate game could use it.  The "simpler"
> this game to play, the more fragile the system is (ie, just using exit codes
> is simple, but fragile; using other IPC mechanisms could be made robust, but
> is not simple - especially not in a platform independent way.)

Right.  They may not need to be platform independent though, if there is
some sort of API in the middle.

Perhaps there should be a framework that with calls that a program can
make to indicate normal exit, fatal (non-restartable) exit, and non-fatal
(restartable) exit. A long-runing-process manager could provide some
way of handling these events as well as handling exits without an aplication
having signalled onde of these events.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org