On Thu, Mar 29, 2007 at 02:49:36PM -0500, Frank Wiles wrote:
> On Thu, 29 Mar 2007 10:12:00 +0100
> Stephane Chazelas <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Mar 28, 2007 at 11:46:15AM +0100, Stephane Chazelas wrote:
> > > 1. Problem Description:
> > >
> > > Hiya,
> > >
> > > After querying a mod_perl run CGI, the corresponding apache2
> > > process ends up having its fd 0 and/or fd 1 closed. This then
> > > causes some other CGIs (for instance mod_python's viewvc) to
> > > fail because they are not robust enough to cope with a closed
> > > fd 0.
> >
> > I should add that this is how mod_perl is told to run the CGI
> > script:
> >
> > <IfModule mod_perl.c>
> > <Location /cgi-bin/gnatsweb.pl>
> > SetHandler perl-script
> > PerlResponseHandler ModPerl::PerlRunPrefork
> > PerlOptions +ParseHeaders
> > </Location>
> > </IfModule>
> >
> > I disabled mod_perl for now. But could anyone please indicate
> > whether I'm not using it properly or whether it is indeed a bug
> > or whether that version of Apache is not supported?
>
> Hi Stephane,
>
> This isn't a bug, but a normal aspect of mod_perl. You can however
> re-tie them. I think this page gives you all the info you need:
>
>
> http://perl.apache.org/docs/1.0/guide/porting.html#STDIN__STDOUT_and_STDERR_streams
[...]
Hi Frank,
the problem I'm talking about is not that the CGI's STDIN/STDOUT
is reaffected. IT's normal for a normal CGI operation, it's that
the fds 0 and 1 are not restored when modperl returns, so that
other handlers run afterwards by the same Apache process (here
my problem was with mod_python) get messed up.
And if you look carefully at the traces, even for the CGI, maybe
perl's STDIN/STDOUT /handles/ were reaffected, but they were not
affected fds 0 and 1, it was not a dup, the CGI's
print STDOUT "...";
actually did a write(16, "..."), so STDOUT was affected another
fd that 1. Tomorrow, I'll try doing a system() within perl, but
I suspect for instance system("echo foo") will no output
anything to the socket.
Cheers,
Stephane
