[ZODB-Dev] ZEO signal feature

[Chris McDonough]

> > This message should probably go to stdout or stderr.
>
> Unclear.  It seems that stdout+stderr are effectively ignored
because
> of the way zdaemon works.  (I played with zdaemon yesterday and
found
> that zdaemon throws aways stdout+stderr, so the only place you can
see
> even the most basic tracebacks is in the logs.

Redirecting stderr and stdout to /dev/null was meant to prevent
problems where the controlling terminal disappears from a controlled
process that sends output to either stderr or stdout.  Zope would die
with an IOError if it tried to write to a nonexistent terminal.  It's
a game of whack-a-mole to find all the places in the code where output
will go to stdout/stderr (e.g. medusa/asyncore).

It might be the right thing to do to fix the code that sends to stderr
instead, although it's a lot of work and not as effective.

> > The logfile should be opened as the effective user.  Pidfiles too.
>
> No argument there.  Just the observation that it's tricky to open
and
> bind the socket earlier than the logfile, given how the code is
> structured, at least in ZEO: the order of execution is something
like
>
>  1. open logfile
>  2. setuid(nobody)
>  3. open storage(s)
>  4. create storage server, passing the storages
>
> The storage server creates and binds the socket.  Fixing this would
> require some significant restructuring of ZEO: the socket is
actually
> opened by asyncore, in a subclass of of asyncore.dispatcher.  At
least
> three software layers would have to be changed in order to open and
> bind the socket before calling setuid().

I think the right thing to do is to replace the zLOG logger.  The new
logger should send log messages to stdout or stderr by default until
you specifically poke a "real" file handler into it (after you've
dropped privileges).  I'm not sure how to handle the redirection of
stderr/stdout to /dev/null in this case, but I think it's just a
matter of messing around with it until it begs for forgiveness. ;-)

> > The only real purpose to running as root is to be able to bind to
> > low-numbered TCP ports.  I've been trying to get the time to fix
> > this in Zope as well.
>
> In practice ZEO is never used with a low-numbered port AFAIK.  So
why
> do we run ZEO as root at all?  Perhaps ZEO should set the uid
> immediately upon starting -- that avoids the restructuring I
mentioned
> above.

One reason to run ZEO as root is because its often called from system
rc scripts.  It almost never works like you want it to (for the
reasons we've been talking about), though, so I often write Zope/ZEO
rc scripts that look something like:

su - zopeuser -c "/home/zopeuser/somezope/z2.py -X -w 8080"

It would be nice to not have to do this.

- C