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=20866>. 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=20866 cgi script just hangs at end, then apr_bucket_read error ------- Additional Comments From [EMAIL PROTECTED] 2003-06-22 21:12 ------- I left the above-mentioned two URL's online, but I made a few changes to them. This is interesting. When I adjust the mysql SQL query to get back only 5 or 10 rows, the bug goes away for the "bug" script. But when I adjust it to get back 71 rows, then the bug exists. Basically, I adjusted my "buged" script: http://www.hotdlz.com/apachebug/ again, that is a script that does a perl "require" to another script that actually does the sql and html output. That require'd script is now set to give out 71 rows from the mysql query, and the foreach loop has a 'warn "foo"' inside each iteration of the loop, and the bugged script has $|=1 at the top too. The other script, http://www.hotdlz.com/apachebug1.pl is identical in that it calls scripts that are identical except the require'd perl script has no $|=1 and no warn "foo" in the foreach. Both do return 71 rows. So the problem script would end up writing "foo" to STDERR over 70 times while the non-problem script would write nothing. I wonder if that has something to do with the problem? Note that I disabled the output of the SQL queries, so if you go to those URL's you won't see much, but you will see apache hang for 5 minutes on www.hotdlz.com/apachebug/ Now for some comments: > Can you try lsof to see if another process has a > descriptor to that same pipe? I'm not sure how to do this, but I'll try: I ran the http://www.hotdlz.com/apachebug/ let it do its pause, then I did this command as root: lsof | grep IPv4 | grep 'my.ip.address' and I found one line: httpd 19860 nobody 37u IPv4 59112398 TCP server.ip.address:http->my.client.ip.address:61975 (ESTABLISHED) In fact that lsof line stays there for the entire 5 minutes. The moment the 5 minute timeout occurrs, Apache writes that ap_content_length_filter: apr_bucket_read() failed line to the error log, and the lsof line disappears. > A commmon problem is a script that writes a bunch > to stderr and ends up hanging on the write because > Apache hasn't started reading that pipe yet. > (This may be depending on scriptlog setting... > can't recall at the moment.) I have no scriptlog setting in my httpd.conf > Does the script write a bunch to stderr? yes, as I mentioned above, the problem script will write a bunch of non- buffered ($|=1) output to STDERR. > This contradicts your statement that ps doesn't > show the script still running actually I believe I was mistaken. A ps does indeed show the perl script is still running. Obviously the first question would be, does the script in fact take 5 minutes to run, but no, if I run the script on the command line with the same enviornment variables as Apache, it runs and terminates normally in about 2 seconds. > If you can figure out a small-ish script to > allow us to duplicate the problem, we're in business. I tried to make a small script that shows this problem, but I had no luck. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
