Bug 479463 - Bad file descriptor: apr_file_close(child input)
Summary: Bad file descriptor: apr_file_close(child input)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: httpd
Version: 5.2
Hardware: i686
OS: Linux
low
low
Target Milestone: ---
: ---
Assignee: Joe Orton
QA Contact: BaseOS QE
URL:
Whiteboard:
Depends On:
Blocks: 837642
TreeView+ depends on / blocked
 
Reported: 2009-01-09 19:56 UTC by Carlos Rodrigues
Modified: 2012-07-04 14:25 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 837642 (view as bug list)
Environment:
Last Closed: 2009-09-02 11:50:30 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Apache Bugzilla 9644 0 None None None Never
Red Hat Product Errata RHBA-2009:1380 0 normal SHIPPED_LIVE httpd bug fix update 2009-09-01 11:48:49 UTC

Description Carlos Rodrigues 2009-01-09 19:56:13 UTC
Description of problem:
I have a cluster of two RHEL 5.2 machines running Apache, in which I've configured a small perl script to be invoked as an input filter (mod_ext_filter) on access to a certain URL.

Now, this is working fine, except for the message that is logged to the Apache error log every time the script is invoked.

This seems to be a known bug (#9644 in the Apache bugzilla) which is already fixed in later versions of Apache. Any chance of having this fix backported to RHEL in the near future?

How reproducible:
Always

Steps to Reproduce:
1. Configure Apache to use an input filter with mod_ext_filter;
2. Go into the URL that triggers the filter;
3. Look at the error log.
  
Actual results:
An error containing the message "Bad file descriptor: apr_file_close(child input)" is logged every time.

Comment 1 Carlos Rodrigues 2009-01-09 20:03:47 UTC
BTW, the referred bug in the Apache bugzilla refers to Apache 2.0. I'm seeing this in the RHEL 5.2' Apache (2.2).

Comment 2 Joe Orton 2009-01-13 13:18:01 UTC
The referenced bug was fixed back in 2.0.37.

Can you give an exact mod_ext_filter configuration which reproduces this?

Comment 3 Carlos Rodrigues 2009-01-13 13:40:29 UTC
The following virtual-host uses SSL.


<VirtualHost *:8443>
    ...

    ExtFilterDefine my-filter mode=input cmd="/etc/httpd/scripts/my-filter.pl" enableenv=my-auth

    <Location /path/>
        SetInputFilter my-filter
        ExtFilterOptions LogStderr

        SetEnvIfNoCase Request_Method "POST" my-post
        SetEnvIfNoCase Request_URI "/object\.dll$" my-post my-auth

       ...
    </Location>
</VirtualHost>

Comment 4 Carlos Rodrigues 2009-01-13 13:42:54 UTC
The location "/path/" is later defined as a proxy with ProxyPass and ProxyPassReverse.

Comment 5 Carlos Rodrigues 2009-01-13 13:53:23 UTC
Sorry for the bug spam, but I have something else to add. This doesn't seem to always be reproducible with Internet Explorer 7 as the client. But with Firefox it is.

As far as user-agent specific configuration goes, I'm using the RHEL defaults, which means this is the only bit that explicitely matches MSIE7:

SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

Comment 11 errata-xmlrpc 2009-09-02 11:50:30 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1380.html


Note You need to log in before you can comment on or make changes to this bug.