Mark Hammond wrote:
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 to get timeout from) on initial startup.
If the file doesn't exist or the lock succeeds, the process is
nonrestartable.
If it exists and cannot be locked (Zope has locked it, signifying
successful startup), the process is restartable.
This lets the parent know of successful startup, but doesn't help it during
the 'starting' phase (if the lock never gets set, how long do we wait before
giving up?) Ditto for shutdown - after requesting the child shutdown, how
long do we wait for it to terminate?
A single timeout leaves us where we started - it is too fragile to assume
that if the app has not started after x seconds, it never will. By having
the child actively report progress, the parent process can be more confident
it is alive and normal, even if it is taking a very long time to start.
Wouldn't a socket work? As the parent process is starting the child, it
could pass the port on the cmdline.
I think by *describing* the API, I made it sound more complicated than it
is. It consists of 2 functions:
def reportState(state, timeout, error_info = None):
Called by the child process, and implemented by the parent.
Reports the status of the child process to the parent.
state may be 'starting', 'running', 'stopping', 'stopped',
'pausing' or 'paused'.
timeout is how long before the parent will consider us dead
if we don't report progress again.
error_info may be specified as the program reports 'stopped'.
If None, the shutdown was normal.
# This second one is optional, but abstracts away using signals :)
def changeState(new_state):
Called by the parent process, and implemented by the child.
Requests that the client process enter the specified state.
Only 'running', 'stopped' and 'paused' are valid (ie, the
parent must never request any of the transition states)
If we ignore the second and stick to signals, it seems fairly robust and
achievable.
The other option is that we get rid of the 'parent' service all together.
Just have the service code use run.py directly, and run it in-process. The
Windows builtin 'auto-restart' facilities for services can handle the
bizarre errors, and offers the benefit of allowing the user to define the
restart policy (even allowing them to reboot should it go down wink).
There may be good reasons for that though.
I still think we should look at making a Windwos version of the
'zdaemon' handler, which uses a Unix-domain socket between parent and
child: we could either use a named pipe on Windows, or else a socket on
localhost, to achieve the same ends.
This would have the upside that 'zopectl' would work the same way on
windows, as well, which would be a boon for WIndows-based developers.
Tres.
--
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation Zope Dealers http://www.zope.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
