On Tue, Sep 24, 2002 at 10:54:50PM -0400, [EMAIL PROTECTED] wrote: > On Tue, 24 Sep 2002, Greg Stein wrote: > > > Just ran into an interesting bug, and I've got a proposal for a way to solve > > it, too. (no code tho :-) > > > > If a CGI writes to stderr [more than the pipe's buffer has room for], then > > it will block on that write. Meanwhile, when Apache goes to deliver the CGI > > output to the network, it will *block* on a read from the CGI's output. > > > > See the deadlock yet? :-) > > > > The CGI can't generate output because it needs the write-to-stderr to > > complete. Apache can't drain stderr until the read-from-stdout completes. In > > fact, Apache won't even drain stderr until the CGI is *done* (it must empty > > the PIPE bucket passed into the output filters). > > > > Eventually, the deadlock resolves itself when the read from the PIPE bucket > > times out. > > > > [ this read behavior occurs in the C-L filter ] > > > > [ NOTE: it appears this behavior is a regression from Apache 1.3. In 1.3, we > > just hook stderr into the error log. In 2.0, we manually read lines, then > > log them (with timestamps) ] > > Is there a reason we don't go back to what 1.3 did? That would seem to be > the easiest way to solve this problem. I am pretty sure that the reason > this was changed originally, was that the first version of apr_proc_create > couldn't do what 1.3 did. Although we should double check on that.
I've gotta say that I like the current behavior where each line of the error log is timestamped. In the old code, the CGI program could spam anything there, in any format. As far as I can tell, the 1.3 CGI system relied on Apache's stderr pointing to the error log. We would need to do that, and let CGI's share the same stderr, or maybe somehow get the fd that we use for the error log and hook that into the CGI's stderr. Note that hooking stderr like that also obviates log levels and syslog logging. It eliminates the timestamp,s annotation of the client IP and other, similar bits. Cheers, -g -- Greg Stein, http://www.lyra.org/
