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.


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

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 (eg,
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 wrapper, and obviously is not a general

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

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.


> 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 Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
Zope Corporation
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to