Bug 1476294

Summary:	mod_wsgi fails to log python errors
Product:	Red Hat Enterprise Linux 7	Reporter:	rh-bugzilla <rh-bugzilla>
Component:	mod_wsgi	Assignee:	Luboš Uhliarik <luhliari>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE - Apps <qe-baseos-apps>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	7.3	CC:	bnater, jorton, luhliari, sebastiaan
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-06-17 10:51:25 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description rh-bugzilla@ar-ix.net 2017-07-28 14:27:13 UTC

Description of problem:
When having a virtualhost with a mod_wsgi application in apache (e.g. <VirtualHost 10.1.2.3:80>) and the python program throws an error it appears in the defined error_log.

If the VirtualHost is rewritten to be an SSL enabled host (e.g. <VirtualHost 10.1.2.3:443>) with the exact same wsgi parameters and application the errors do NOT appear in the defined error_log.

If however the VirtualHost is changed to <VirtualHost *:443> the errors are appearing in the error_log. 

If the port is other than 80 you appear to need to use * instead of an IP to see python errors.

We found an Ubuntu bug from 2011 which shows the same thing:
https://bugs.launchpad.net/ubuntu/+source/mod-wsgi/+bug/908605

It would be nice if we can define an SSL-enable VirtualHost to bind to an IP-address and still have python errors logged to the defined error_log.


Version-Release number of selected component (if applicable):

mod_wsgi.x86_64                 3.4-12.el7_0

Comment 2 Joe Orton 2017-07-28 19:04:28 UTC

Thank you for taking the time to report this issue to us. We appreciate the
feedback and use reports such as this one to guide our efforts at improving our
products. That being said, this bug tracking system is not a mechanism for
requesting support, and we are not able to guarantee the timeliness or
suitability of a resolution.

If this issue is critical or in any way time sensitive, please raise a ticket
through the regular Red Hat support channels to ensure it receives the proper
attention and prioritization to assure a timely resolution.

For information on how to contact the Red Hat production support team, please
visit:
    https://www.redhat.com/support/process/production/#howto

Comment 3 rh-bugzilla@ar-ix.net 2017-07-31 07:20:59 UTC

Hi Joe,

Thank you for your response. To remove any possible confusion, this ticket was not meant as a support request. Our problem is fixed by replacing the IP-address with an asterisk. 
This ticket was meant to bring this issue to the attention to you so it can possibly be fixed in the future. Also it's a nice reference for people who might struggle with the same issue.

Comment 9 RHEL Program Management 2020-06-17 10:51:25 UTC

Development Management has reviewed and declined this request. You may appeal this decision by using your Red Hat support channels, who will make certain  the issue receives the proper prioritization with product and development management.

https://www.redhat.com/support/process/production/#howto