Re: [Fwd: DO NOT REPLY [Bug 43491] New: - Piped ErrorLog regression: two piped program started, one attached to tty]
On 09/27/2007 12:40 AM, William A. Rowe, Jr. wrote: Still debugging, but go ahead and commit your patch; tag it up for backports. You already have my +1 that it's the right fix. As the patch is part of your larger patch I wait to commit to make it easier for others to apply the larger patch. Regards Rüdiger
Re: [Fwd: DO NOT REPLY [Bug 43491] New: - Piped ErrorLog regression: two piped program started, one attached to tty]
On Sep 26, 2007, at 4:45 PM, Ruediger Pluem wrote: On 09/26/2007 07:30 PM, William A. Rowe, Jr. wrote: In the current log.c code, although the write-end of an initial error logger is still held by the parent --- until the second logger process has kicked off. It seems someone's inherited that write end. I have a two line patch attached that Funny. Two people getting to the same patch independently :-). So yes, I think your patch does the correct thing. +1 Needs some review before we kick off 2.2.7 into the real world, since we close that write end of the logger right after we've launched the logger. Wondering if this might not be a prefork, worker or event mpm specific failure case. I don't think so. +1 as well...
[Fwd: DO NOT REPLY [Bug 43491] New: - Piped ErrorLog regression: two piped program started, one attached to tty]
In the current log.c code, although the write-end of an initial error
logger is still held by the parent --- until the second logger process
has kicked off. It seems someone's inherited that write end. I have
a two line patch attached that
Needs some review before we kick off 2.2.7 into the real world, since
we close that write end of the logger right after we've launched the
logger. Wondering if this might not be a prefork, worker or event mpm
specific failure case.
This patch wasn't for this bug, it was strictly for common sense, but
I'm wondering if it doesn't have a side effect of solving the bug;
Bill
Index: server/log.c
===
--- server/log.c (revision 579397)
+++ server/log.c (working copy)
@@ -414,6 +414,12 @@
unable to replace stderr with error_log);
}
else {
+/* We are safer having only a single apr_file_t reference
+ * to the new main error logging stream
+ */
+apr_file_close(s_main-error_log)
+s_main-error_log = stderr_log;
+
/* We are done with stderr_pool, close it, killing
* the previous generation's stderr logger
*/
---BeginMessage---
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=43491.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43491
Summary: Piped ErrorLog regression: two piped program started,
one attached to tty
Product: Apache httpd-2
Version: 2.2.6
Platform: Other
OS/Version: AIX
Status: NEW
Severity: normal
Priority: P2
Component: Core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Pb was reproduced with 2.2.6 on AIX and Solaris.
Once piped log are configured (ex with rotatelogs), if you start Apache, you
will find two copies of the errorlog piped program:
- one has been started a few seconds prior to the second one
- the first one has parent pid=1 (not httpd) and is attached to your tty
Example below:
UID PIDPPID CSTIMETTY TIME CMD
root 1761522 1 0 18:28:05 - 0:00 httpd -k start
1892358 1761522 0 18:28:05 - 0:00 httpd -k start
root 1077456 1 0 18:28:02 pts/12 0:00 rotatelogs errors.%Y%m%d 86400
root 2170970 1761522 0 18:28:05 - 0:00 rotatelogs errors.%Y%m%d 86400
Since the first one is attached to your tty, you can no longer exit your ssh
connection easily nor automate things with remote shell commands
Located the pb in server/log.c: latest revision commited in 2.2.x branch
introduced the regression
http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/server/log.c?
r1=569542r2=570451diff_format=h
Note: if first piped program is killed, no prob since the second one is the
one doing the job
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---End Message---
Re: [Fwd: DO NOT REPLY [Bug 43491] New: - Piped ErrorLog regression: two piped program started, one attached to tty]
On 09/26/2007 07:30 PM, William A. Rowe, Jr. wrote: In the current log.c code, although the write-end of an initial error logger is still held by the parent --- until the second logger process has kicked off. It seems someone's inherited that write end. I have a two line patch attached that Funny. Two people getting to the same patch independently :-). So yes, I think your patch does the correct thing. Needs some review before we kick off 2.2.7 into the real world, since we close that write end of the logger right after we've launched the logger. Wondering if this might not be a prefork, worker or event mpm specific failure case. I don't think so. Regards Rüdiger
Re: [Fwd: DO NOT REPLY [Bug 43491] New: - Piped ErrorLog regression: two piped program started, one attached to tty]
Ruediger Pluem wrote: On 09/26/2007 07:30 PM, William A. Rowe, Jr. wrote: In the current log.c code, although the write-end of an initial error logger is still held by the parent --- until the second logger process has kicked off. It seems someone's inherited that write end. I have a two line patch attached that Funny. Two people getting to the same patch independently :-). So yes, I think your patch does the correct thing. Needs some review before we kick off 2.2.7 into the real world, since we close that write end of the logger right after we've launched the logger. Wondering if this might not be a prefork, worker or event mpm specific failure case. I don't think so. I don't think so, either, this licks it. I do believe we have one last bug in mpm_winnt to solve, because with the state of my (heavily-patched) trunk, I'm arriving with stderr_file of NULL in the ap_open_logs, and they should already have a static stderr_file. This is in the win32 child, and not the parent. Still debugging, but go ahead and commit your patch; tag it up for backports. You already have my +1 that it's the right fix. Bill
