Can't we just parse the log files, or maybe even have a special logger for Window Service, and wait for this?
2004-08-03T15:37:55 INFO(0) Zope Ready to handle requests If the process dies after this, restart. Em Seg, 2004-08-09 �s 10:56, Chris McDonough escreveu: > 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: > > [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. (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? > > > > Thanks, > > > > Mark. > > > > _______________________________________________ > > 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 ) > > > > _______________________________________________ > 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 ) > _______________________________________________ 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 )
