[ZODB-Dev] Daemon manager design issues

[Jeff Rush]

As the maintainer of Zope/ZEO RPMs, as well as an ISP
that runs multiple customer Zope instances, I've
wrestled with a bit of these issues.

I'd like to see an approach based on /sbin/init, where
something like /etc/inittab lists instances and I can
switch Zope 'runlevels' to bring up/down groups of
instances.  Say, level 3 for full-up, level 2 for 
shutting down just Zope clients but leaving ZEOs up,
and level 1 for all-down.  Multiple such files could
exist for flexibly grouping instances.

And for system boot/shutdown, a single command to
bring up/down all instances would be easier to use
than an long list of start/stop cmds in rc.init.

And the separate utility might have status reporting
features, giving a snapshot of servers up/down like
ps or top.

I realize this goes beyond a 'simple' daemon manager
but I don't think its much more of a step for the
parent to watch N child processes.

Guido van Rossum wrote:
> 
> I've got some design questions where I'd like to hear from potential
> users (especially since this will be used to run Zope too, and I don't
> know much about running Zope myself).
> 
> - There needs to be a way to stop the daemon manager (and the daemon
>   application).  Shall I do this with a signal or with a separate
>   utility that talkes to the daemon manager, perhaps through a
>   Unix-domain socket?

A separate utility.  While signals is more in keeping with
current Red Hat conventions, I think a separate utility
is cleaner.  Underneath you could use either a .pid/signal
or Unix-domain socket approach, since you'd need a way
to specify the location of a control file either way.

The separate utility ought to provide a way to query the
up/down status.  The Red Hat utilities need that.

And underneath, I vote for signals, since you can first
ask nicely (SIGTERM) and after no timely child-end, ask
forcibly (SIGKILL).  Otherwise if the child hangs, no
Unix-domain socket request will work.


> - Ditto for restarting the daemon application.  I guess this has to
>   kill the application with a signal, unless we want to get fancy and
>   decide on a separate parent-child protocol (which I think would be
>   overkill).  We could do this in three ways:
> 
>   - Use a separate utility as described above.
> 
>   - Send the signal directly to the application (this means there has
>     to be a file with the application's pid; the daemon can write
>     this);
> 
>   - Send the signal to the manager, which passes it on.

A separate utility.


> - Logging is configured through environment variables, which are
>   passed on to the application.  Is there a need to be able to
>   configure the manager's logging separately from the application, or
>   is it okay that the manager always logs to the same file as the
>   application?

Single log stream -- although having each line prefixed to enable
sorting later would be a nice option, and probably useful for
debugging.  Also being able to specify a different Syslog Facility
name, to enable splitting that way.


> - Are there any other features missing from the daemon manager?

[1] basic protection against starting the same instance twice;
    the current zdaemon doesn't stop this

[2] You may already do this (I haven't checked your source) but
    zdaemon ought to 'cd' into the Zope/var directory to avoid
    unnecessarily holding onto directories.

[3] when writing the .pid, abort if any existing such file has
    incorrect settings (is a symlink?)

-Jeff Rush