FWIW, the equivalent of the service manager code under UNIX is "zopectl" rather than runzope.
Ahh, ok. That makes more sense now, thanks.
When you say "these errors" above, do you mean any unhandled exception? If so (and any nonzero exit code indicated a startup failure), would we really need cooperation from run.py for this? It seems like it could be done entirely inside of SvcDoRun.
Yes, that is what I tried to say 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.
As the exit code of 1 is the only way I see to detect an unhandled exception in the child.
OTOH, if the "real" problem is that you can't stop the service from fruitlessly restarting itself in the face of an insoluble error because of the blocking sleep, it seems like you already solved that.
Yeah, it really isn't a huge issue. It leaves us with the fact that Zope always reports startup success, even in hopeless cases. This isn't a real problem - just a nicety - along the lines of making Zope a first-class service on Windows <wink>. I'm happy to let that idea rest. To your other mail:
Do you think you might be able to attach your patched service.py (and related files) to a future mail?
I'll attach the patch in private mail. I just tried attaching it to collector 1020, but I don't have permission. It has the redirection and the sleep fix, but no changes to the startup strategy.
It actually impossible to *stop* Zope from using pieces of another system-installed Python, given that it apparently looks unconditionally to the registry to find some things.
Yes, and it is my fault that code even exists. As far as I know, win32all was the only product that registered modules in this way, and later versions no longer do. I'd be +1 on getting this removed from Python. Thanks, Mark.