On 12.01.2009 11:19, Rainer Jung wrote:
On 12.01.2009 10:04, Joe Orton wrote:
On Sun, Jan 11, 2009 at 05:36:07PM -0000, [email protected] wrote:
Author: rjung
Date: Sun Jan 11 09:36:07 2009
New Revision: 733493

URL: http://svn.apache.org/viewvc?rev=733493&view=rev
Log:
Allow to trigger rotatelogs log file rotation from
using HUP and INT signals to the rotatelogs process.

This is helpful, when log activity is low, but you want
rotatelogs to close the open log files.

Sending SIGTERM to the rotatelogs process and having the parent recycle
it should have done that already, surely, without adding all this
complexity to rotatelogs?

Thanks for the hint. In fact I just tested it and it does work for
rotatelogs used in CustomLog, but not for the ErrorLog one. That one
simply dies, no automatic restart and further error messages are lost
(quickly tested on Solaris, and only with 2.2.x, needs some further
testing for trunk).

It's the same for trunk: CustomLog automatically gets respawned, ErrorLog not.

The code uses ap_open_piped_log() in server/log.c to open access logs. This in turn uses piped_log_spawn(), which registers piped_log_maintenance() using apr_proc_other_child_register().

In piped_log_maintenance() the logger is automatically restarted using again piped_log_spawn(), when the conditions for restarting are appropriate. All this is true if AP_HAVE_RELIABLE_PIPED_LOGS is defined.

ErrorLog is handled by open_error_log() also in server/log.c. This calls log_child(), which uses apr_proc_create() to create the logger, but does not register any restarter.

When AP_HAVE_RELIABLE_PIPED_LOGS is not set, access log handling works like error log handling, i.e. without automatic restart. Reliable piped logs seem to be used, whenever APR defines APR_HAS_OTHER_CHILD, which seems to be true by default (no auto-detection).

Does it make sense to add the reliable piped logs way of handling loggers to the error log? Or is there any known dependency between the code used in ap_open_piped_log() and the error log itself?

Regards,

Rainer

Reply via email to