You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by "lrf.2@juno.com" <lr...@juno.com> on 2009/09/01 17:46:15 UTC
RE: [users@httpd] httpd 2.0.63 + cgi script + 'Error: Bad file number
'
Hi Boyle Owen,
>> I am attempting to upgrade my apache installation from
>> the 1.3.x branch to the 2.0.x or, perhaps 2.2.x branch,
>If you're going to upgrade, why not go all the way to 2.2.13? The 2.0
>branch has not been updated since January 2008 and is not developed >any more.
Good point. I went with 2.0.63 because the issue appeared when
we attempted to replace the 1.3.x version of apache we are using
with the IBM IHS 6.1 server which is built on 2.0.47 and patched
to 2.0.63. My thinking was to attempt to isolate the issue to
apache or IBM's modification of it. Unfortunately, the problem
appears under both platforms. I have also attempted using
2.2.13 with precisely the same issue.
>> security reasons on AIX running 5.2.0.8. I built httpd
>> 2.0.63 from source and configured it to be the same as the
>> 1.3.x version was configured. But when we attempted to use a
>> cgi script that has run flawlessly under httpd 1.3.x, it
>> failed with 'Operating system error: Bad file number'.
>> Other cgi scripts continue to operate.
> Where did you get the error? Switch on ScriptLog and check there.
> Also, check the code of the CGI program and look for file-handling
> calls to see if you can narrow down where the error is coming from.
This is the flow of the process: A user brings up the login screen,
enters their userid and password, and clicks submit. That posts a
call to a cgi script that parses the submission and calls another
script to verify the userid/password and extract that user's job
code from the database, placing that job code in a file to be parsed
by the calling script upon return. The script that verifies the
userid/password calls two compiled programs: one verifies the
userid and password are valid, the other makes the call to the
database to extract the job code. The call to verify the userid
and password succeeds but the call to the database fails.
ScriptLog does not give me anything. The output from the script
is redirected to a file and the failed script does not emit anything
aside from it's stdout message and a return code of 255. The script
executes flawlessly under apache 1.3.x and from the command line as
the same user as under apache. I do not have the source for the
script; it is a compiled application that makes a database call.
Any ideas as to how I can debug this further?
> Rgds,
> Owen Boyle
> Disclaimer: Any disclaimer attached to this message may be ignored.
Thank you for your assistance!
Lee
____________________________________________________________
Best Weight Loss Program - Click Here!
http://thirdpartyoffers.juno.com/TGL2131/fc/BLSrjnsEGrEal0sXmK3ceVgwSXiWn3UvduQYE1h6Mnl9fWb4lEP8U7gjtwk/
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: [users@httpd] httpd 2.0.63 + cgi script + 'Error: Bad file number'
Posted by Boyle Owen <Ow...@six-group.com>.
> -----Original Message-----
> From: lrf.2@juno.com [mailto:lrf.2@juno.com]
> Sent: Tuesday, September 01, 2009 5:46 PM
> To: users@httpd.apache.org
> Subject: RE: [users@httpd] httpd 2.0.63 + cgi script +
> 'Error: Bad file number'
>
> Hi Boyle Owen,
>
> >> I am attempting to upgrade my apache installation from
> >> the 1.3.x branch to the 2.0.x or, perhaps 2.2.x branch,
>
> >If you're going to upgrade, why not go all the way to 2.2.13? The 2.0
> >branch has not been updated since January 2008 and is not
> developed >any more.
>
> Good point. I went with 2.0.63 because the issue appeared when
> we attempted to replace the 1.3.x version of apache we are using
> with the IBM IHS 6.1 server which is built on 2.0.47 and patched
> to 2.0.63. My thinking was to attempt to isolate the issue to
> apache or IBM's modification of it. Unfortunately, the problem
> appears under both platforms. I have also attempted using
> 2.2.13 with precisely the same issue.
>
> >> security reasons on AIX running 5.2.0.8. I built httpd
> >> 2.0.63 from source and configured it to be the same as the
> >> 1.3.x version was configured. But when we attempted to use a
> >> cgi script that has run flawlessly under httpd 1.3.x, it
> >> failed with 'Operating system error: Bad file number'.
> >> Other cgi scripts continue to operate.
>
> > Where did you get the error? Switch on ScriptLog and check there.
> > Also, check the code of the CGI program and look for file-handling
> > calls to see if you can narrow down where the error is coming from.
>
> This is the flow of the process: A user brings up the
> login screen,
> enters their userid and password, and clicks submit. That posts a
> call to a cgi script that parses the submission and calls another
> script to verify the userid/password and extract that user's job
> code from the database, placing that job code in a file to
> be parsed
> by the calling script upon return. The script that verifies the
> userid/password calls two compiled programs: one verifies the
> userid and password are valid, the other makes the call to the
> database to extract the job code. The call to verify the userid
> and password succeeds but the call to the database fails.
>
> ScriptLog does not give me anything. The output from the script
> is redirected to a file and the failed script does not
> emit anything
> aside from it's stdout message and a return code of 255.
> The script
> executes flawlessly under apache 1.3.x and from the command line as
> the same user as under apache. I do not have the source for the
> script; it is a compiled application that makes a database call.
>
> Any ideas as to how I can debug this further?
Not really... Are you using a worker or prefork MPM? Apache 1.3 is
worker only (daemons, not multi-threaded). If you are using a
multi-threaded apache there could be synchronization issues, especially
with DB but that's just a shot in the dark. Otherwise, I found this
thread: http://www.perlmonks.org/?node_id=636194 but it's not really too
similar...
Rgds,
Owen Boyle
Disclaimer: Any disclaimer attached to this message may be ignored.
>
> > Rgds,
> > Owen Boyle
> > Disclaimer: Any disclaimer attached to this message may be ignored.
>
> Thank you for your assistance!
>
> Lee
>
>
> ____________________________________________________________
> Best Weight Loss Program - Click Here!
> http://thirdpartyoffers.juno.com/TGL2131/fc/BLSrjnsEGrEal0sXmK
> 3ceVgwSXiWn3UvduQYE1h6Mnl9fWb4lEP8U7gjtwk/
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP
> Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message.
The sender's company reserves the right to monitor all e-mail communications through their networks.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org