[ZODB-Dev] Daemon manager design issues

[Guido van Rossum]

[me]

I don't hear back from anybody, I'll probably do the following, to
simplify my life (despite my deep distrust for signals):

> - 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?

Send SIGTERM to the manager; it writes a pid file given by a command
line arg.

> - 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.

Other signals to the manager are passed on to the application, as the
current zdaemon.Daemon module does.  There's no way to force a restart
of the application without also restarting the manager, but that's
apparently okay.

> - 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?

Keep the current situation, i.e. the manager and application have the
same logging configuration.

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