[ZODB-Dev] Daemon manager design issues

[Guido van Rossum]

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

Thanks!  Very useful feedback.

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

Hmmm...  Maybe I can do something using the new ZConfig stuff.

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

Yes, but it won't be able to tell you much more than whether the
process exists or not -- beyond that is a world of system specific
hacks that I'd rather not duplicate from ps or top etc.

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

Actually, the step from watching 1 to watching 2 processes is probably
the most significant rewrite imaginable.  After that, generalization
to N is trivial. :-)

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

Question, how do you know that the same "instance" is already up,
without building in a lot of knowledge about the application?  I think
that's better left to the application (e.g., Zope, or the ZEO
StorageServer, or Squid, or whatever).

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

Good point.  The question is, how to decide which directory to chdir
into without building in too much knowledge about the application.  I
want this to be fully general.

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

Why?  I know you mean this as a security measure, but I'm unclear why
the pid file would be any more vulnerable than, say, the Data.fs, or
any other file written by any of these tools.  What's the specific
attack scenario you're thinking about?

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