> 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
> 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.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -