Bug 54221 - no ErrorLog prefix on CGI errors
Summary: no ErrorLog prefix on CGI errors
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_cgid (show other bugs)
Version: 2.4.3
Hardware: Sun Solaris
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
: 60692 62483 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-11-28 22:40 UTC by Mark Tischler
Modified: 2021-02-25 10:38 UTC (History)
2 users (show)



Attachments
error log snippet from before the upgrade (664 bytes, text/plain)
2012-11-28 22:40 UTC, Mark Tischler
Details
error log snippet from after the upgrade (1.26 KB, text/plain)
2012-11-28 22:41 UTC, Mark Tischler
Details
config file (30.72 KB, text/plain)
2012-11-28 22:41 UTC, Mark Tischler
Details
old config file (31.08 KB, text/plain)
2012-11-29 15:13 UTC, Mark Tischler
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Tischler 2012-11-28 22:40:42 UTC
Created attachment 29647 [details]
error log snippet from before the upgrade

Was running Apache 2.2.15 up until mid-October.  Then upgraded to Apache 2.4.3.  There are statements that are coming out in the error log rather routinely, so they were coming out before the upgrade, and they are coming out since the upgrade.  These are generated by some web application running a shell script on our web server.  The problem is that these lines lack full information in the new Apache version, which makes debugging hard.  I have been searching the internet on and off for the past several weeks trying to figure out what might be wrong, but have had no success.  So, unfortunately, I'm having to resort to this method of solving my problem.  I have attached a file snippet from our error log *prior* to the upgrade, a file snippet from our error log *after* to the upgrade, as well as our httpd.conf.  In the case of the two file snippets, you will see that the information associated with the middle 4 lines is severely lacking in the one from *after* our upgrade.  Can you identify if there's a problem in our configuration, or if there is something wrong with Apache?
Comment 1 Mark Tischler 2012-11-28 22:41:29 UTC
Created attachment 29648 [details]
error log snippet from after the upgrade
Comment 2 Mark Tischler 2012-11-28 22:41:50 UTC
Created attachment 29649 [details]
config file
Comment 3 Mark Tischler 2012-11-28 22:48:01 UTC
Note that I'm just giving one example of this.  There are many more lines that come out in the error log without any additional information.  I haven't been able to establish a pattern of what gets printed with additional information and what does not.
Comment 4 Eric Covener 2012-11-29 00:14:04 UTC
LoadModule info_module modules/mod_info.so
	# mdt - 2012-09-14 - comment out because this module is not built by default as of Apache 2.4.2
#LoadModule cgi_module modules/mod_cgi.so
	# mdt - 2012-09-14 - add this module to take the place of mod_cgi as of Apache 2.4.2
LoadModule cgid_module modules/mod_cgid.so

Did your logging difference happen during the change from mod_cgi to mod_cgid?

Did you change your MPM as well?
Comment 5 Mark Tischler 2012-11-29 15:06:02 UTC
I made the change from mod_cgi to mod_cgid simultaneous with the move from 2.2.15 to 2.4.3, so I don't know what caused it.  As I noted in the httpd.conf, I had to make that change to get things to work.  Should I have done something different?

I do not know what MPM is, so I guess I don't know if changed it.  I will attach my old httpd.conf -- the one from 2.2.15.  Perhaps that answers this question.
Comment 6 Mark Tischler 2012-11-29 15:13:47 UTC
Created attachment 29657 [details]
old config file
Comment 7 Mark Tischler 2013-01-07 21:45:44 UTC
Eric,

You were so good about responding quickly the first time.  Any thoughts on what the problem might be?
Comment 8 Eric Covener 2013-01-07 22:23:27 UTC
The prefix is a difference between mod_cgi and mod_cgid.
Comment 9 Mark Tischler 2013-01-07 22:28:38 UTC
So, are you saying that I need to load mod_cgi instead of mod_cgid?  If so, as I recall (it's been several months, though), when I tried loading mod_cgi, it told me that this module was obsolete (you actually captured this implication in your Nov. 29th response).  So, how do you suggest I get mod_cgi to work?  At the time, my only recourse seemed to be to *not* load mod_cgi, but to instead load mod_cgid.
Comment 10 Eric Covener 2013-01-07 22:32:16 UTC
I'm only saying it's the explanation of the different behavior when you changed from one CGI module to the other, which had been misinterpreted as something that changed just due to the update.
Comment 11 Mark Tischler 2013-01-07 22:34:15 UTC
So, are you confirming that I can no longer use the mod_cgi module with Apache 2.4.3?  And, if so, are you saying that there is no way to get the prefixes back?
Comment 12 Eric Covener 2013-01-07 22:47:42 UTC
There's no new restrictions on mod_cgi in 2.4.  Just like in 2.2, you can only use it with the prefork MPM, not worker or event.
Comment 13 Mark Tischler 2013-01-07 22:50:19 UTC
Then I'm confused.  What would I have inadvertently changed so that I'm not using prefork MPM in Apache 2.4 vs. (apparently I was) in Apache 2.2?  Is there something in the httpd.conf files for 2.2 and 2.4 that leads to that answer?
Comment 14 Eric Covener 2013-01-07 23:16:01 UTC
(In reply to comment #13)
> Then I'm confused.  What would I have inadvertently changed so that I'm not
> using prefork MPM in Apache 2.4 vs. (apparently I was) in Apache 2.2?  Is
> there something in the httpd.conf files for 2.2 and 2.4 that leads to that
> answer?

It's a build time decision in 2.2.  In 2.4, you can build multiple MPM's and choose whichever you like at runtime by LoadModule on exactly one.
Comment 15 Mark Tischler 2013-01-07 23:20:52 UTC
OK.  So, I'm looking for some advice on how to configure the httpd.conf for 2.4.3, so that I get the correct module(s).  As I said, when I tried to load mog_cgi, it complained.  It sounds (from what you're saying) that I simply need to adjust the httpd.conf to load some new or different modules.
Comment 16 Eric Covener 2013-01-07 23:34:40 UTC
http://httpd.apache.org/userslist.html
Comment 17 Mark Tischler 2013-01-29 19:01:26 UTC
OK.  So, I rebuilt the web server, this time with the '--enable-cgi' flag in the config for both building Apache as well as PHP.  I loaded the mod_cgi module instead of the mod_cgid module, ran the following script, and still got the problem:

<?php
print "Content-type: text/html\n\nhi\n";
$STDERR = fopen('php://stderr', 'w+');
fwrite($STDERR, "Error: cannot execute query\n");
?>

Running this as a URL, yields simply:

Error: cannot execute query

instead of something like:

[Tue Jan 29 12:51:44.330891 2013] [:note] [pid 19732:tid 5] [client 135.185.197.151:3798] Error: cannot execute query

You had said that it was because I was now using mod_cgid, instead of mod_cgi.  Given that I am now using mod_cgi and I still have this problem, what's the next step?
Comment 18 Mark Tischler 2013-02-11 20:14:01 UTC
Eric, I need advice from you.  This is not something I can go to the forums with, because I need insider knowledge of what's causing this issue.  You had one theory, but, either there's something additional at play, or there is something completely different causing this.  Please respond with your insight.
Comment 19 Eric Covener 2013-02-11 20:30:04 UTC
I have no idea, you'll have to wait for a volunteer to look further.  Are you sure your PHP runs as CGI?
Comment 20 Mark Tischler 2013-02-11 20:53:31 UTC
The .php script I included above is run as a web page under that newly-built web server, so it should be running as a built-in, not CGI, because I build PHP with Apache.  At least, that's the way I was understanding it.  Besides the .conf file, which I attached to the ticket, I could include the instructions I used to build the product, if you think that would help.

When you say that I would have to wait for another volunteer to see and grab this ticket, it's been 2 weeks since I posted that even using mod_cgi didn't help.  So, what time period would I expect to have to wait until someone else jumps in?  How does someone know that you are "detaching" from this ticket?  Perhaps every other volunteer figures that you are still handling it, and, thus, they do not need to jump in.
Comment 21 Eric Covener 2013-02-11 21:11:13 UTC
> When you say that I would have to wait for another volunteer to see and grab
> this ticket, it's been 2 weeks since I posted that even using mod_cgi didn't
> help.  So, what time period would I expect to have to wait until someone
> else jumps in?  How does someone know that you are "detaching" from this
> ticket?  Perhaps every other volunteer figures that you are still handling
> it, and, thus, they do not need to jump in.

Bugzilla isn't for support, It's for reporting bugs. 

It's still unclear what component writes to your error log differently after your upgrade and reconfguration, but no matter what it is originators are expected to do their homework in the report.

Anyone who takes interest is always free to comment.    Again, I think you might get some guidance on the users list which has more eyes.
Comment 22 Mark Tischler 2013-02-11 21:33:00 UTC
The problem is that this appears to me to be a bug.  I think I have followed the instructions to build a web server properly, but, as yet, there's been no explanation as to why it doesn't work the way it used to work.  Once there's a plausible explanation (and I thought it was that I was supposed to use mod_cgi instead of mod_cgid) as to why it's not working, then, to me, it would make sense to go to the user list.
Comment 23 Mark Tischler 2013-02-28 16:26:32 UTC
No one has responded to this ticket in a very long time.  If, indeed, Eric, you were waiting for someone else to jump in and take it (as you indicated on February 11), it appears that nothing is triggering anyone else to look at this.  Is there a way to trigger someone else to look at this in a timely fashion?
Comment 24 Eric Covener 2013-03-01 21:38:28 UTC
(In reply to comment #23)
> No one has responded to this ticket in a very long time.  If, indeed, Eric,
> you were waiting for someone else to jump in and take it (as you indicated
> on February 11), it appears that nothing is triggering anyone else to look
> at this.  Is there a way to trigger someone else to look at this in a timely
> fashion?

I'm not waiting for anything. We're all volunteers motivated by different things without any implied level of service.   As an originator, the best you can do is provide your own detail and analysis to not reduce the overhead of whoever looks at the bug report.

On 2.4, I can switch between mod_cgid and mod_cgi and run a CGI that does:

echo "XXX CGI TEST" >&2

And with mod_cgi, it shows up with the erorrlog prefix, and with mod_cgid it shows up without it.

I confirmed on 2.2, mod_cgid behaves the same as it does in 2.4. I didn't bother testing mod_cgi in 2.2.

I didn't go back to 2.2.15, just 2.2.latest.  You'll need a more concrete reproducible report to minimize the effort of anyone trying to find the bug here.
Comment 25 Mark Tischler 2013-03-07 22:21:12 UTC
I'm not sure what else someone would need.  I provided the httpd.conf files from 2.2.15 and 2.4.3, and I provided an actual example on my posting of 2013-01-29 19:01:26 UTC.
Comment 26 Joe Orton 2019-07-05 10:28:52 UTC
*** Bug 62483 has been marked as a duplicate of this bug. ***
Comment 27 Joe Orton 2019-07-17 12:37:46 UTC
This is now fixed experimentally as an opt-in feature on trunk via r1862968 and  r1863191 

I have a 2.4.x backport of the required changes which enables them unconditionally: 

http://people.apache.org/~jorton/httpd-2.4.x-cgid-fdpassing.patch

Testing with this patch is very welcome, and please report any results here.
Comment 28 Joe Orton 2019-07-17 12:40:25 UTC
*** Bug 60692 has been marked as a duplicate of this bug. ***
Comment 29 Joe Orton 2021-02-25 10:38:15 UTC
As of r1886912 this is now enabled by default for 2.5.x, so marking fixed. It's an increasingly complex set of changes so I may update the 2.4.x backport and propose for inclusion at some point, but not guaranteed.