The product is failing to initialize and Zope refuses to start as a result. Nothing is written to the log due to the decision to defer logging to a file until after we've been able to do some houskeeping (which, ironically, is vital under UNIX but totally unnecessary under Windows).
Should we rethink about this decision?
The log file has been the main source to analyse startup problems. How should they be analysed for Zope 2.7?
Well, I don't think so. Here's why. A failing startup can be debugged via looking at console output. This is simple on UNIX, and would have been simple under Windows had I corrrectly used "python.exe" instead of "pythonw.exe" in the runzope.bat batch file. When someone asks why Zope doesn't start under UNIX and there are no messages in the event log file, the stock answer will be "run it using the 'runzope' shell script in a console window". When someone asks why Zope doesn't start under Windows, the stock answer will be "run it using the 'runzope.bat' batch file in a console window." I think that's acceptable. FWIW (and you probably know this already, but others might not), the reason for holding off on logging startup messages to a log file is to allow the application time to setuid before writing any log files, so that if Zope is initially started as root, subsequent startups under a nonroot user account won't fail due to an inability to write to the logfile (which would be owned and writable only by root). This is (or at least used to be) a frequent source of complaints on the list for all previous Zope versions. All that said, I think (over time) we might be able to do less before we have the opportunity setuid so that these kinds of messages would indeed be written to the logfile. - C