Bug 474230 - mod_proxy breaks existing applications with RHEL-5.3beta update.
mod_proxy breaks existing applications with RHEL-5.3beta update.
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: httpd (Show other bugs)
All Linux
low Severity high
: rc
: ---
Assigned To: Joe Orton
Depends On:
  Show dependency treegraph
Reported: 2008-12-02 16:19 EST by Stephen John Smoogen
Modified: 2009-01-13 12:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-13 12:07:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stephen John Smoogen 2008-12-02 16:19:08 EST
Description of problem:

updated httpd's mod_proxy breaks cobbler utility. 

from the email list it turns out that the updated httpd breaks expected functionality that was worked in RHEL-5 before (and probably works the same in newer versions of upstream Fedora.) I have included Micheal from RH to help explain better what he is seeing.

What we've found out is that if Apache connects to itself within
mod_python via a mod_proxy URL, bad things happen.

So if you change (Apache proxied XMLRPC endpoint) to just (python directly)

everything works great.

Rather than hard code the port, I'm going to make it read the settings
file to get the port number, but basically that's the workaround.

I suspect this /is/ a bug in mod_python and/or mod_proxy though I'm not
sure the extent of it's seriousness and am ultimately ok with the

Comment 1 Michael DeHaan 2008-12-02 16:22:03 EST
I was going to ask first if this should be expected to work, but since the bug is filed, here's the rest of my details sent to Joe Orton (who Koji says is the package owner)


A cobbler user found a /potential/ problem in mod_python RHEL 5.3 that I wanted to ask about.

A xmlrpclib-using mod_python handler (services.py) tries to connect back through Apache on a mod_proxied url like:

xmlrpclib.Server(", allow_none=True)

which is configured as

ProxyRequests off
ProxyPass /cobbler_api http://localhost:25151/
ProxyPassReverse /cobbler_api http://localhost:25151/

This seems to work fine on 5.2, but on 5.3 produces:

  1. Core was generated by `/usr/sbin/httpd'.
  2. Program terminated with signal 11, Segmentation fault.
  3. [New process 10332]
  4. #0  0x00d2b717 in ap_update_child_status (sbh=0x0, status=3,
     r=0x0) at /usr/src/debug/httpd-2.2.3/server/scoreboard.c:448
  5. 448        return
     ap_update_child_status_from_indexes(sbh->child_num, sbh->thread_num,
  6. (gdb) where
  7. #0  0x00d2b717 in ap_update_child_status (sbh=0x0, status=3,
     r=0x0) at /usr/src/debug/httpd-2.2.3/server/scoreboard.c:448
  8. #1  0x00d331ef in core_create_conn (ptrans=0x90c3030,
     server=0x8fe23f0, csd=0x90c3068, id=0, sbh=0x0, alloc=0x90c9048)
     at /usr/src/debug/httpd-2.2.3/server/core.c:3907
  9. #2  0x00d427a3 in ap_run_create_connection (p=0x90c3030,
     server=0x8fe23f0, csd=0x90c3068, conn_id=0, sbh=0x0,
     alloc=0x90c9048) at /usr/src/debug/httpd-2.2.3/server/connection.c:40
 10. #3  0x00603a9f in ap_proxy_connection_create
     (proxy_function=0xfac628 "HTTP", conn=0x90c1060, c=0x9148c60,
     s=0x8fe23f0) at
 11. #4  0x00faabef in proxy_http_handler (r=0x9154af8,
     worker=0x90385b8, conf=0x9038190, url=0x91492a8 "/",
     proxyname=0x0, proxyport=0) at
 12. #5  0x005fe660 in proxy_run_scheme_handler (r=0x9154af8,
     worker=0x90385b8, conf=0x9038190, url=0x9155d8e
     "http://localhost:25151/", proxyhost=0x0, proxyport=0)
 13.     at /usr/src/debug/httpd-2.2.3/modules/proxy/mod_proxy.c:2345
 14. #6  0x006028d3 in proxy_handler (r=0x9154af8) at
 15. #7  0x00d3a97d in ap_run_handler (r=0x9154af8) at
 16. #8  0x00d3e328 in ap_invoke_handler (r=0x9154af8) at
 17. #9  0x00d4a43e in ap_process_request (r=0x9154af8) at
 18. #10 0x00d471df in ap_process_http_connection (c=0x9148c60) at
 19. #11 0x00d4284d in ap_run_process_connection (c=0x9148c60) at
 20. #12 0x00d4294c in ap_process_connection (c=0x9148c60,
     csd=0x9148ac8) at /usr/src/debug/httpd-2.2.3/server/connection.c:178
 21. #13 0x00d4edb2 in child_main (child_num_arg=<value optimized out>)
     at /usr/src/debug/httpd-2.2.3/server/mpm/prefork/prefork.c:640
 22. #14 0x00d4f0c1 in make_child (s=0x8fe23f0, slot=1) at
 23. #15 0x00d4f19a in startup_children (number_to_start=7) at
 24. #16 0x00d4fcfb in ap_mpm_run (_pconf=0x8fe0550, plog=0x900e608,
     s=0x8fe23f0) at
 25. #17 0x00d26147 in main (argc=150857160, argv=0x0) at

I'll admit there is no reason for Apache to proxy through itself though it used to work.

Comment 2 Joe Orton 2008-12-03 03:33:51 EST
Please try the updated httpd packages from here:

Comment 3 Joe Orton 2009-01-13 11:25:27 EST
Did you confirm that the updated httpd packages fixed all the problems you were seeing?
Comment 4 Michael DeHaan 2009-01-13 11:30:51 EST
Sorry, I did not.

I fixed this by not having the mod_python stuff proxy through Apache.

So rather than having the mod_python component connect through I just have it do (or whatever port number).
Comment 5 Joe Orton 2009-01-13 12:07:19 EST
OK, no worries.  Since the backport looks identical to the known-and-fixed bug in the 5.3 beta packages, I'm going to close this out as presumed fixed.

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