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:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
