DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13511>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13511

Apache misbehaves if log files can't be written





------- Additional Comments From [EMAIL PROTECTED]  2002-10-17 18:08 -------
Re: multiple CGI processes - it their output was tee'd directly from
stderr to a log file, the output from multiple processes would be 
chaotically interspersed.  That in itself would be a problem. The 
output from DTDOUT is clearly handled individually, so why not STDERR?

For the momement, lets separate the question of what happened to 
this particular CGI from that happens in general.

1) For this particular CGI, a warning message caused the process to terminate,
effectively turning friendly glitch audit trail into a black hole.  Clearly 
not a desirable outcome.

2) From the viewpoint of apache as a whole, if log files are not being 
maintained
and processes are being killed randomly, the system as a whole is in serious
jeopordy.  Perhaps Apache should shut down (which will surely get someone's
attention) but at the very least there should be an emergency channel of some
sort throug which apache reports serious internal problems.  The standard log
files are not a good place for this, because apache's (rare we hope) internal
problems would be lost in mountains of routine log data.

Consider the current case; Apache knows exactly what is wrong, and can/should
tell the sysop "error log can't be written".    Consider the current behavior
as a debugging problem "my email arrived blank".  Which would you rather deal
with?

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to