Ressurecting a bit of an old thread:
From: Chris McDonough [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 4 August 2004 11:19 PM
Subject: Re: [Zope-dev] Possible Windows Service improvements.
...
I'm a Windows signal idiot.
I was too. I think I understand them a little better now after having
Would a lockfile work ok to signify running state? IOW, Zope would
lock a file as one of the last steps during startup (which it actually
does now, but might do it a bit too early). The Windows
service manager
would attempt to lock the same file after timeout seconds (although
I'm not sure
Would a lockfile work ok to signify running state? IOW, Zope would
lock a file as one of the last steps during startup (which it actually
does now, but might do it a bit too early). The Windows service manager
would attempt to lock the same file after timeout seconds (although
I'm not sure where
[Me]
By adding a layer around run.py, I believe we could arrange
for these fatal errors to be handled with a special return code.
[Jim]
I assume by fatal, you mean errors that we should not try to restart
from.
Correct.
Let me see if I understand the use cases here:
- Normal shutdown.
Some quick hit-and-runs.
[Mark Hammond]
FWIW, the way to do that better was to use WaitForSingleObject(hStopEvent,
timeout_period*1000).
[Cris McDonough]
Is this a more-or-less direct replacement for the usage of time.sleep()
in the current incarnation of SvcDoRun?
The Windows
You left out the lack of 'zopectl debug' ;] I have managed to create it
though
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Mark Hammond
Sent: Wednesday, August 04, 2004 7:35 AM
To: [EMAIL PROTECTED]
Subject: [Zope-dev] Possible Windows Service
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
On Wed, 2004-08-04 at 07:35, Mark Hammond wrote:
Hi all,
I am starting to venture into the wonderful world of Zope! With the
benefit of a complete lack of Zope experience, I have been able to look at
the Windows service support from a fairly clean slate. However, I also
realize this lack
Mark Hammond wrote:
...
I propose:
We insist the child process can be created and continues to run for x
seconds (where x~5).
I recommend against this strategy. It's too implicit and has bitten us on
Unix in the past. The problem with the strategy if the program starts very fast
and then dies,
[Me]
I propose:
We insist the child process can be created and continues to
run for x seconds (where x~5).
[Jim]
I recommend against this strategy. It's too implicit and has
bitten us on
Unix in the past. The problem with the strategy if the
program starts very fast
and then dies, we
I propose:
Each time the child process terminates with a non-zero
return code, the tail
x-bytes of the child output be written to the Windows event
log, where x~2k.
This is a good idea. FWIW, I believe the Zope HEAD already has some
work done towards this (in
On Wed, 2004-08-04 at 19:56, Mark Hammond wrote:
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
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
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
14 matches
Mail list logo
