Re: svn commit: r733493 - in /httpd/httpd/trunk: CHANGESdocs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xmlsupport/rotatelogs.c

[Rainer Jung <ra...@kippdata.de>]

On 12.01.2009 10:04, Joe Orton wrote:
> On Sun, Jan 11, 2009 at 05:36:07PM -0000, rjung@apache.org 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).

> A lot of the stuff you're doing in the new signal handler is not
> async-signal safe, so -1.  (closeFile notably calls pool functions)

Yes. I'll see whether I could safely work around that.

After I will have investigated more about your above hint and the 
possibilities of implementing it async signal safe, we might have 
another check, whether the use case makes sense as an internal 
functionality of rotatelogs or not?

Regards,

Rainer

Re: svn commit: r733493 - in /httpd/httpd/trunk: CHANGESdocs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xmlsupport/rotatelogs.c

[Rainer Jung <ra...@kippdata.de>]

On 12.01.2009 18:59, William A. Rowe, Jr. wrote:
> Rainer Jung wrote:
>> 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?
>
> When I was looking at this, the difference didn't make a whole lot of sense
> to me, but I was not trying to make any mass changes, only more subtle
> changes that corrected the number of open and lingering fd's.  Provided
> that your patch to be consistent in registering reliable restart info
> does work as a per-host error logger and the global stderr logger, I'd
> say go ahead for 2.3 alpha.

I'll see how far it gets. Your comments and Joe's indicate, that it's 
worth investigating.

> But it would be interesting to look at this historically, why error loggers
> were not in the original reliable piped logs implementation code path?

I just checked, and the same construction and difference between access 
and error log was already in 1.3.0. From the changes, reliable piped 
logs have been introduced in 1.3b2, but I didn't check that code version 
to see, if it looks the same. The changes file doesn't have an entry 
about error log changes w.r.t. the piped logging between 1.3.b2 and 1.3.0.

What can be seen from the CHANGES file, is that the logging of some 
modules that also allow the use of piped logging, has been switched to 
the new implementation only in later versions. So it's possible it was 
done only for access from the start and whenever someone stumbled over 
another case of piped logging, it was switched to the reliable pipes.

Regards,

Rainer

Re: svn commit: r733493 - in /httpd/httpd/trunk: CHANGESdocs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xmlsupport/rotatelogs.c

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Rainer Jung wrote:
> 
> 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?

When I was looking at this, the difference didn't make a whole lot of sense
to me, but I was not trying to make any mass changes, only more subtle
changes that corrected the number of open and lingering fd's.  Provided
that your patch to be consistent in registering reliable restart info
does work as a per-host error logger and the global stderr logger, I'd
say go ahead for 2.3 alpha.

But it would be interesting to look at this historically, why error loggers
were not in the original reliable piped logs implementation code path?

Bill

Re: svn commit: r733493 - in /httpd/httpd/trunk: CHANGESdocs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xmlsupport/rotatelogs.c

[Joe Orton <jo...@redhat.com>]

On Mon, Jan 12, 2009 at 12:03:31PM +0100, Rainer Jung wrote:
> On 12.01.2009 11:19, Rainer Jung wrote:
>> On 12.01.2009 10:04, Joe Orton wrote:
>>> 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.
...

Sorry, my mistake, I hadn't realised the piped error-logs code was 
different in this respect.  Your analysis looks spot on here anyway.

> 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?

Well, I certainly had the expectation that piped error-loggers were 
automatically restarted; I don't know if there's some technical reason 
why it's not done, I expect it's just an oversight.

Regards, Joe

Re: svn commit: r733493 - in /httpd/httpd/trunk: CHANGESdocs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xmlsupport/rotatelogs.c

[Rainer Jung <ra...@kippdata.de>]

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, rjung@apache.org 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