[ZCM] [ZC] 1285/10 Edit "[Weakness] analysis of Zope startup problems (log hidden)"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #1285 Update (Edit) "[Weakness] analysis of Zope startup problems (log hidden)"
 Status Accepted, Zope/bug medium
To followup, visit:
  http://www.zope.org/Collectors/Zope/1285

==============================================================
= Edit - Entry #10 by ajung on Apr 9, 2005 3:51 am

 Changes: edited transcript, importance (critical => medium)
________________________________________
= Comment - Entry #9 by efge on Nov 18, 2004 11:37 am

[fdrake]
The stuff in Zope 2.8 certainly starts using the final logging
configuration sooner for Windows than for Unix (it switches to the
configured logging as soon at it has the configuration).  Someone may
be able to improve on it, and it may be that those changes can be
backported to Zope 2.7.

________________________________________
= Comment - Entry #8 by ajung on Nov 18, 2004 8:25 am

The following patch for lib/python/Zope/Startup/__init__.py
is running in our environment. It takes the filename from
$ZOPE_STARTUP_LOG and logs all related startup messages if
the variable is set....a dirty hack but it works for us...

139c139,140
<             self.startup_handler = StartupHandler(open(devnull, 'w'))
---
>             devnull = os.environ.get('ZOPE_STARTUP_LOG', devnull)
>             self.startup_handler = StartupHandler(open(devnull, 'a'))

________________________________________
= Edit - Entry #7 by efge on Nov 18, 2004 8:14 am

 Changes: edited transcript, revised title, new comment

[chrism]
Zope doesn't log anything until it is able to get to the point where it
sets the effective uid.  This is of course useless on Windows and in
most cases on UNIX when you're not running Zope under the root account.
If anyone has some patches which preserves the spirit of this behavior
but allows logging to happen sooner, they're welcome.

________________________________________
= Comment - Entry #6 by fdrake on Nov 2, 2004 12:30 pm

I have very little time right now.

Question:  Does 2.8 do the right thing, or are people unhappy with that as well?

I'm generally hesitant to make changes to the Zope 2 startup sequence these days, since there doesn't appear to be any agreement about how it should work.

I'd love to see a fishbowl proposal that describes in great detail how startup should be handled.  I suspect we do better in 2.8, but it needs to become better documented outside the code.

________________________________________
= Comment - Entry #5 by ajung on Nov 2, 2004 11:00 am

Fred, any chance to get this problem solved?
________________________________________
= Edit - Entry #4 by ajung on Nov 2, 2004 10:59 am

 Changes: submitter email, importance (medium => critical)
________________________________________
= Comment - Entry #3 by ajung on May 12, 2004 10:57 am

Can we have a fix for this issue before 2.7.1 beta?
________________________________________
= Assign - Entry #2 by fdrake on Apr 30, 2004 11:14 am

 Status: Pending => Accepted

 Supporters added: fdrake

Assigned to myself since I've had my hand in startup logging recently.
________________________________________
= Request - Entry #1 by d.maurer on Apr 2, 2004 3:32 am

Zope 2.7 delays access to log files until Zope is properly set up.
This means: log files cannot be used to analyse startup problems.

The official advice to analyse startup problems is to start
Zope in the foreground and interpret the console log messages.

However, this does *NOT* work when Zope is not running in
debug mode. "Zope.Startup.ZopeStarter.setupStartupHandler"
expressly suppresses messages to "stderr" when Zope
is not running in debug mode.

Apparently, we do not have an easy way to analyse startup problems
for Zope in production mode.
In my view, this is really bad.


Please provide a way to control how startup messages should
be handled. The best place would be a file (at least for
all installations that do not start Zope as root and later
switch the effective user).

I suggest to always use the standard log file unless
told otherwise by an explicit configuration option.

==============================================================