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]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce