[Zope-dev] Possible Windows Service improvements.

[Chris McDonough]

On Wed, 2004-08-04 at 20:24, Mark Hammond wrote:
> > This is a good idea.  FWIW, I believe the Zope HEAD already has some
> > work done towards this (in
> > lib/python/nt_svcutils/service.py), although
> > the child output goes to a logfile instead of the event log.  It would
> > be nice to make the output go to the event log and then
> > backport this to
> > 2.7.
> 
> I started from HEAD, and indeed did find a good attempt at making this work.
> However, it was disabled by default, it writes to a file, and had issues
> with blocking reads.  I fixed this to capure the output in memory (but not
> all of it - just the tail), and to use a single pipe for both stdout and
> stderr.

Great!

> > Yup.  The reason it retry-restarts is because it's simple and
> > stupid and
> > the reason it doesn't respond to shutdown requests during a retry is
> > because the service code sleeps for the backoff interval after an
> > unsuccessful startup.  Any async requests that happen in the meantime
> > are blocked waiting for this sleep to end.  I'm not quite
> > sure how to do
> > that better.
> 
> FWIW, the way to do that better was to use WaitForSingleObject(hStopEvent,
> timeout_period*1000).

Is this a more-or-less direct replacement for the usage of time.sleep()
in the current incarnation of SvcDoRun?

Do you think you might be able to attach your patched service.py (and
related files) to a future mail?

> > Others have
> > claimed this is unnecessary and that the work that gets done in there
> > could be done in the service code.  It's a bit of a mess.
> 
> I agree with the others :)  mkzopeinstance goes to lengths to provide all
> relevent information, and the service code does not take full advantage of
> that.
> 
> It should be possible for Zope to work with a standard, external
> Python/pywin32 installation.  I'm not suggesting this become a distribution
> option, but still a worthy goal; for developers, and to keep us honest
> <wink>.  Note that with a few tweaks, Zope *does* build and work with an
> external Python/pywin32.

Yup, it should be possible; there's really nothing special about the
Zope-supplied Python, we just have a history of attempting to make Zope
install under Windows without requiring that the user know anything
about Python, and the easiest way to do this is to ship our own.

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.
(See the thread revolving around
http://mail.zope.org/pipermail/zope-dev/2004-March/021979.html for the
details).  This is actually not a desirable feature.

> > At one point
> > I flailed trying to make the child process inherit its
> > environment from
> > the parent, and plastered over the problem with various sys.path and
> > PYTHONPATH and other environment variable settings.  The current
> > situation is a result.  Some guidance here would be helpful.
> 
> The child process *does* inherit the parent, service environment.  Hence
> adding os.environ[] entries in the service does set them for subsequently
> created children.
> 
> ie, setting os.environ["PYTHONPATH"]=SOFTWARE_HOME in the service main code
> appears to avoid the sitecustomize.py requirement - the child process *does*
> see the new PYTHONPATH.

Yup, that confirms what the thread above says too.

> > I'm a Windows signal idiot.
> 
> No - Windows is a signal idiot :)

Actually, signals are idiotic, but... ;-)

> > Is there a way that we can make the Zope
> > process capture Windows signals and when the Windows equivalent of
> > SIGTERM is sent to the process to shut it down "cleanly"?  This is how
> > it works on UNIX
> 
> That makes sense, but:
> 
> > but we circumvent trying to listen for signals on
> > Windows entirely at startup.
> 
> Can you explain the above?  Do you mean that on Windows, you take no special
> signal actions, as demonstrated in WindowsZopeStarter.registerSignals?

That's just what I mean.

The signaling mechanism doesn't necessarily need to literally be
"signals", I just don't know of another way to asynchronously influence
the state of a running process (UNIX or Windows).  Maybe Zope needs to
cooperate a bit, which would be fine.

> I'll see what I can come up with though.
> 
> > Note that the UNIX environment has a lot of additional niceties due to
> > responses to signals (like logfile rotation) that Windows doesn't now,
> > which tends to have the effect of relegating Windows to a second-class
> > platform on which to run a production Zope instance.
> 
> Windows certainly has these features available - they are just not always
> spelt the same as they are on Unix.  Sometimes they are even better <wink>.
> So there seems to be a chicken-and-egg problem - users will always consider
> it second class until Zope itself starts considering it first class.  This
> is an observation, not a critisism :)

Sure.  It probably won't take much work to match the features that are
available under UNIX.

FWIW, Tim (most recently), I (second-most-recently), and Brian Lloyd
(least recently) are really the only people who have put a concerted
effort into keeping Zope running and installable acceptably under
Windows.  Ironically, I have no excuse; I don't use Windows as a server
platform and I've never actually had a customer who did.  Tim has an
excuse (he still works for ZC, which apparently does have customers that
use Windows as a server platform, and he uses Windows himself), but I
think everyone would agree that he really should be working on more
important things.  Brian has long ago disavowed any knowledge of making
Zope run under Windows.  So in other words, it's probably a very good
thing you're here! ;-)

- C