[Zope-dev] Possible Windows Service improvements.

[Mark Hammond]

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