[Zope-Coders] new zLOG

Guido van Rossum guido@python.org
Tue, 26 Nov 2002 11:15:58 -0500


> > This sounds like a good reason to not introduce two new envvars
> > (EVENT_LOG_FILE and EVENT_LOG_SEVERITY) and only support the old ones
> > for backwards compatibility (STUPID_LOG_FILE and STUPID_LOG_SEVERITY),
> > if (as you say) using the files in a production setting is stupid.
> 
> This change was introduced in 2.6, not by my latest checkins.

OK, then it has to stay.  The change definitely caused problems though:
all places that *set* STUPID_LOG_* must be fixed to set both STUPID_*
and EVENT_*.  I remember staring at why some test I didn't write
was failing with logging turned on.  It was because the test expected
that setting STUPID_LOG_FILE had a specific effect, which it didn't
because I had set EVENT_LOG_FILE...

> > > It needs to be fixed, and, for Zope, it even *has* been fixed on a
> > > branch.  I hope to convince folks to see a need for it in ZEO as well.
> > 
> > The new zdaemon.py script calls setuid() before even forking the
> > server subprocess.  Currently it only does this if you explicitly
> > specify -u, but it's easy to do change this to call setuid() by
> > default when invoked by root.
> 
> Looks good.  It looks like you were careful to not write to zLOG in
> zdaemon itself until after a setuid (was this intentional)?

Yes. :-)

> I think it's the right thing to *not* have zdaemon perfom setuid by
> default if started as root because you may want the child process
> have privileges to bind to low ports and whatnot and manage its own
> setuid.

OK, then I'll leave well enough alone.

> > OK, I'll check a change to zLOG in soon (without API, let's call it a
> > YAGNI).
> 
> Thanks.

You're welcome.

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