Re: svn commit: r733493 - in /httpd/httpd/trunk: CHANGESdocs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xmlsupport/rotatelogs.c
On 12.01.2009 10:04, Joe Orton wrote: On Sun, Jan 11, 2009 at 05:36:07PM -, rj...@apache.org wrote: Author: rjung Date: Sun Jan 11 09:36:07 2009 New Revision: 733493 URL: http://svn.apache.org/viewvc?rev=733493view=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? 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) I send a patch for trunk to the list, including reliable piped logging for the error loggers. Coming back to adding complexity: as you might have noticed I added a bit of other functionality to rotatelogs and part of the complexity comes from making it a bit more modular (moving code into functions). The added functionality is: a) allow to rotate based on time *and* size (check both and rotate whenever one of the two criteria applies) b) verbose output (for debugging purposes, log parsed config flags and whenever rotation occurs) c) Allow B, K, G, T as unit characters for sizes in addition to 'M' I really like a) but b) and c) are not that important. Removing b) makes the code shrink about 60 lines. Any preferences? Regards, Rainer
Re: svn commit: r733493 - in /httpd/httpd/trunk: CHANGESdocs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xmlsupport/rotatelogs.c
-Ursprüngliche Nachricht- Von: Rainer Jung Gesendet: Freitag, 16. Januar 2009 11:51 An: dev@httpd.apache.org Betreff: Re: svn commit: r733493 - in /httpd/httpd/trunk: CHANGESdocs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xmlsupport/rotatelogs.c On 12.01.2009 10:04, Joe Orton wrote: On Sun, Jan 11, 2009 at 05:36:07PM -, rj...@apache.org wrote: Author: rjung Date: Sun Jan 11 09:36:07 2009 New Revision: 733493 URL: http://svn.apache.org/viewvc?rev=733493view=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? 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) I send a patch for trunk to the list, including reliable piped logging for the error loggers. Coming back to adding complexity: as you might have noticed I added a bit of other functionality to rotatelogs and part of the complexity comes from making it a bit more modular (moving code into functions). The added functionality is: a) allow to rotate based on time *and* size (check both and rotate whenever one of the two criteria applies) b) verbose output (for debugging purposes, log parsed config flags and whenever rotation occurs) c) Allow B, K, G, T as unit characters for sizes in addition to 'M' I really like a) but b) and c) are not that important. Removing b) makes the code shrink about 60 lines. Any preferences? As far as I understand Joe he is mostly concerned about the signal code. So I guess reverting r733493 should be sufficient. All other stuff should be ok. Regards Rüdiger
Re: svn commit: r733493 - in /httpd/httpd/trunk: CHANGESdocs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xmlsupport/rotatelogs.c
On 12.01.2009 10:04, Joe Orton wrote: On Sun, Jan 11, 2009 at 05:36:07PM -, rj...@apache.org wrote: Author: rjung Date: Sun Jan 11 09:36:07 2009 New Revision: 733493 URL: http://svn.apache.org/viewvc?rev=733493view=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
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 -, rj...@apache.org wrote: Author: rjung Date: Sun Jan 11 09:36:07 2009 New Revision: 733493 URL: http://svn.apache.org/viewvc?rev=733493view=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
Re: svn commit: r733493 - in /httpd/httpd/trunk: CHANGESdocs/man/rotatelogs.8 docs/manual/programs/rotatelogs.xmlsupport/rotatelogs.c
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 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
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
