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.
On Sun, 2004-08-08 at 21:10, Mark Hammond wrote:
> > > By adding a layer around run.py, I believe we could arrange
> > > for these fatal errors to be handled with a special return code.
> > I assume by "fatal", you mean errors that we should not try to restart
> > from.
> > Let me see if I understand the use cases here:
> > - Normal shutdown. (Should it be possible to shut down Zope
> > through the web on Windows?)
> I see no reason it makes less sense for Windows than it does for anywhere
> else <wink>.
> > - Start-up error. We want to log relevent information somewhere.
> > We don't want to restart.
> > - Run-time (after startup) error. We also want to log a problem,
> > but we do want to restart Zope.
> Yep, I think that covers it.
> > Note that we also need to consider uncontrolled exits, like segfaults.
> Yes - if the segfault is at startup, it should be considered
> non-restartable. Once normal operations have started, a segfault should
> cause a restart.
> > Perhaps there should be a framework that with calls that a program can
> > make to indicate normal exit, fatal (non-restartable) exit,
> > and non-fatal (restartable) exit.
> That could done with process exit codes if all the child needs to is report
> *exit* status - but that really doesn't cover enough bases. Given the
> number of ways programs can fail, it may be hard to guarantee, and doesn't
> handle uncontrolled exits or children going zombie.
> What we need is something a more authoritative - where the child process
> actively signals its state to the parent - ie "starting", "running" or
> "stopping". "pausing" and "paused" may also make sense. If the child never
> reported 'running', it is non-restartable. If the child terminates without
> reporting graceful shutdown, it is restartable.
> This still does not provide any way of handling the case when the child
> process is running, but failing to transition between states. We still need
> a timeout, but can make it more robust by having the child process report
> the status *and* the timeout the parent should use.
> Which, coincidently, sounds exactly like the Windows Services API <wink>.
> Is that sounding reasonable, or moving into too-complicated/YAGNI territory?
> Zope-Dev maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -