Bug 28025 - Looping cp, mv, or ftp >50 locks cgi script return to client browser
Summary: Looping cp, mv, or ftp >50 locks cgi script return to client browser
Status: RESOLVED DUPLICATE of bug 22030
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: All (show other bugs)
Version: 2.0.49
Hardware: PC Linux
: P3 blocker (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-29 17:06 UTC by John Fauerbach
Modified: 2004-11-16 19:05 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Fauerbach 2004-03-29 17:06:05 UTC
This problem is in Redhat 8.0, Enterprise 3, and the latest httpd (2.0.49)
source code download from apache.org and compiled.  It is also reproducible in
perl.  This script works fine from the command line or under Apache 1.3.x.  You
can substitute different commands for the cp.  I first found it under while
trying to ftp several, > 100 files, then I shortened the code and reproduced it
using cp and mv.  The original problem was when I built a ftp command file
containing all the files to transfer and then it errored at > 50 files.

Steps to Reproduce in Apache 2.0.49 under RH 8.0 and enterprise 3 that does not
exist in Apache 1.3.x under RH 8.0, RH 7.3.  Below is the script to reproduce it:

john.cgi:

#!/bin/bash
echo "Content-type: text/html"
echo ""

var0=0

while [ "$var0" -lt 200 ]
do
echo "$var0 "
cp /tmp/hh /tmp/hI have found a reproducible bug in Apache 2.0.49 under linux
that does not exist in Apache 1.3.x.  Below is the script to reproduce it:

john.cgi:

#!/bin/bash
echo "Content-type: text/html"
echo ""

var0=0

while [ "$var0" -lt 200 ]
do
echo "$var0 "
cp /tmp/hh /tmp/h
cp /tmp/h /tmp/hh
var0=`expr $var0 + 1`
done
echo "It is done\n<P>"

exit 0 
cp /tmp/h /tmp/hh
var0=`expr $var0 + 1`
done
echo "It is done\n<P>"

exit 0 


This script locks up after 68 is prin.

Please help.
Comment 1 Jeff Trawick 2004-03-29 17:27:11 UTC
mod_cgi or mod_cgid?

any messages written to stderr when the cgi script is run?

can you get an strace of the server processing one of these requests?
Comment 2 John Fauerbach 2004-03-29 19:59:32 UTC
1) mod_cgi.c

/usr/local/apache2/bin/apachectl -l
Compiled in modules:
  core.c
  mod_access.c
  mod_auth.c
  mod_include.c
  mod_log_config.c
  mod_env.c
  mod_setenvif.c
  prefork.c
  http_core.c
  mod_mime.c
  mod_status.c
  mod_autoindex.c
  mod_asis.c
  mod_cgi.c
  mod_negotiation.c
  mod_dir.c
  mod_imap.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_so.c

2) how do I get messages written to stderr when the cgi script is run through a
web browser?

3) Don't know how to do a strace.

Comment 3 Jeff Trawick 2004-03-29 20:09:26 UTC
>2) how do I get messages written to stderr when the cgi script is run through a
>web browser?

When a cgi script writes to stderr, the output goes to the web server error log.
 There is a problem currently where a cgi script which writes too much data to
stderr will hang.

Check the web server error log and see if any messages from the cp commands have
been written to the web server error log.

If they have, and the amount is approaching 4K bytes, this is a known problem
and the work-around is to handle stderr somehow within the script.  E.g., if in
your example the cp command is failing (out of space?), invoke cp like this
within the script to see if the hang is resolved:

cp /tmp/hh /tmp/h 2>/dev/null
cp /tmp/h /tmp/hh 2>/dev/null

>3) Don't know how to do a strace.

Note: the previous issue (stderr) is easier to check than this, so don't do this
unless you determine that your script isn't writing a bunch of stuff to stderr.

You need to do this test with a server that isn't actively accessed except when
you are gathering doc for the cgi problem.

Pick a running httpd child process you see in the output of ps -ef.  (Let's
assume this child has pid 12345.)

# strace -o outfile -f -p 12345

Keep issuing the CGI request until a bunch of stuff gets written to outfile.

Attach the trace (outfile) to this PR.  Hopefully this will show why the hang is
occurring.
Comment 4 John Fauerbach 2004-03-30 18:08:49 UTC
The redirection of the output works for the example.  I am looking more into it
to see if it solves the original problem.

Thanks
Comment 5 Joe Orton 2004-06-03 22:34:01 UTC
Since redirecting stderr fixes the issue, presuming this is the CGI stderr
handling bug as Jeff suggests.

*** This bug has been marked as a duplicate of 22030 ***