[ZODB-Dev] Daemon manager design issues

[Guido van Rossum]

> On Monday 11 November 2002 2:34 pm, Guido van Rossum wrote:
> 
> > > I suspect this would be useful, but I would be happy provided I
> > > can get them both to target syslog.
> >
> > Well, if you figure out how to configure zLOG to target syslog,
> > let me know.  All I know is STUPID_LOG_FILE
> 
> Ill do that.
> 
> > > (if we need it, then can we make this behaviour optional please?)
> >
> > What's the use case for making it optional?  Do you have any tools
> > that use exit 2 to signal "please restart me"?
> 
> I have some things that I would like to run as a daemon that should
> always be restarted, and I dont want to think about analyzing their
> exit codes.
> 
> I guess I could handle this with a wrapper script that logged the
> exit code, then exit(1).
> 
> > I realize I forgot something though -- exit 0 should also be taken
> > as "don't restart".  This is consistent with the current zdaemon
> > behavior. I assume this is so that when you use the ZMI to shut
> > down Zope, the daemon manager won't restart it.
> 
> Yes, and yes
> 
> (But I will still be inhibiting this via a wrapper script for
> Zope. I will still be better off than today where I patch the Zope
> source to remove this misfeature)

I can easily make the list of exit codes to interpret as fatal a
command line option.

> > > daemonutils has a working directory for the manager process,
> > > which contains the application start script, its equivalent of
> > > our default runlevels, and the manager control socket. I find
> > > this approach works well. I think it would be fair for the
> > > manager process to chdir into there, and leave Zope to chdir
> > > into Zope/var.
> >
> > Can you suggest a default directory to pick for the daemon
> > manager?  I'd prefer to require as little configuration and setup
> > as possible.  Maybe I should just chdir into /tmp (really
> > tempfile.gettempdir())?
> 
> I think you misunderstand. daemonutils has a working directory for
> each application that it is monitoring.
> 
> http://cr.yp.to/daemontools/supervise.html

OK, but this concept doesn't apply to how I would like the zdaemon
script to work.  Having a directory with a run script is simply not
how I want this to work.

> > > Using the status reporting tool. We protect against two copies
> > > of the manager process, *not* two copies of the application.
> >
> > But how do two copies of the manager process know that they are
> > managing the same application?
> 
> Because they share the same per-application daemon manager working
> directory (assuming we have one ;-)

I currently do this via the name of the unix domain socket used for
communication.

I've decided for now to always cd into /, as part of the daemonizing.
Core dumps of Python aren't very enlightening in my experience, and
the application can cd into its own var directory if it wants to.

--Guido van Rossum (home page: http://www.python.org/~guido/)