[ZODB-Dev] Daemon manager design issues

[Toby Dickenson]

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 alway=
s be=20
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 co=
de,=20
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 wil=
l=20
still be better off than today where I patch the Zope source to remove th=
is=20
misfeature)

> > 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=20
application that it is monitoring.

http://cr.yp.to/daemontools/supervise.html

> > 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 direct=
ory=20
(assuming we have one ;-)

> Anyway, the source looks complicated enough to want to have a Python
> version we can actually understand and hack.

Yes.