> > I propose:
> > We insist the child process can be created and continues to
> > run for x seconds (where x~5).

> I recommend against this strategy.  It's too implicit and has
> bitten us on
> Unix in the past. The problem with the strategy if the
> program starts very fast
> and then dies, we don't restart it even though we should.
> Similarly, if the
> program starts very slowly, we don't recognize a startup
> failure and keep
> retrying even though we shouldn't.

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 run.py, I believe we could arrange for these fatal
errors to be handled with a special return code.  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?
* 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.
* Is a special exit code, generated by a wrapper to run.py (eg, run_svc.py)
suitable?  If so, what value do you recommend?
* Should some Win32 specific, robust IPC mechanism be investigated?  This
would cut deeper into a run.py wrapper, and obviously is not a general

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


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to