[Zope-dev] Possible Windows Service improvements.

[Leonardo Rochael Almeida]

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  -  Zope-Dev at zope.org
> > 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  -  Zope-Dev at zope.org
> 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 )
>