Re: Problems whem upgrading from 4.3.5 to 4.3.6

Eggert Ehmke <[email protected]> writes:
> ...
> Thanks for the hint. Where could I adjust the timeout?

It used to be defined in the "zoperunner" section of the
Zope configuration file ("etc/zope.conf"), documented in
"Zope2.Startup:zopeschema.xml" -- apparently, it has been dropped in
the meantime. In addition, the runner (at least "zdrun.py")
no longer supervises a successful startup of the Zope process - thus,
there should no longer be a need for the option.

In addition, the daemon runner is supposed to use the same
logging configuration as the Zope process itself. However, this
seems not to work. Not sure, there is a way to work around this bug
(and get the daemon logs) -- apart from changing sources.


> It seem to be a systematic problem, now I can see it on three different 
> installations of Plone 4.3.6. I am not sure about 4.3.5, but it definitely did 
> not show up before. The databases are not particular large.

Apparently, you found "SIGTERM" signal log messages in your
logfile. This means that someone/something has sent those signals
to the Zope process. Key to the understanding of your problem
is to find out who/what did this.

Potential candidates:

  *  some supervising/monitoring software (you should know whether you let
     your Zope/Plone processes be supervised)

  *  the daemon process (usually "zdaemon.zdrun").
     Apparently, it no longer sends
     "SIGTERM" signals to the Zope process for startup problems.

     Getting its logging working may give hints whether it is
     responsible

  *  the Zope process itself.

     Usually, it does not do this - however, extensions might
     do it.
     
     As your Zope runs well in "foreground" mode; this is not likely.

  *  the operating system
     
     However, it should write a log message (usually somewhere
     below "/var/log") when it does.

     As your Zope runs well in "foreground" mode, this is not likely.

As your Zope runs well in "foreground" mode (which does not
use a daemon process) but not in "daemon" mode (which uses a
daemon process), indications are strong that something with
the daemon process does not work as it should be.

The most likely cause would be permission problems for the communication
sockets between "zopectl" and "zdrun". However, you have rules out this
cause.


If nothing else helps, you may need to debug the startup process.

The difficult part is the debugging of the daemonized "zdrun"
as "daemonization" has dropped the connection to the terminal
necessary for the debugger interaction. The trick to get
around this difficulty is to force "zopectl" to use "zdrun"
but do not pass to it the request to "daemonize".
You may be able to do this by setting the "daemon" attribute
to "false" in the "zoperunner" section of your "etc/zope.conf" file.


------------------------------------------------------------------------------