[Zope-dev] Possible Windows Service improvements.
Jim Fulton
jim at zope.com
Thu Aug 5 10:36:07 EDT 2004
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
More information about the Zope-Dev
mailing list