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?
Created attachment 29648 [details] error log snippet from after the upgrade
Created attachment 29649 [details] config file
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.
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?
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.
Created attachment 29657 [details] old config file
Eric, You were so good about responding quickly the first time. Any thoughts on what the problem might be?
The prefix is a difference between mod_cgi and mod_cgid.
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.
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.
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?
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.
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?
(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.
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.
http://httpd.apache.org/userslist.html
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?
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.
I have no idea, you'll have to wait for a volunteer to look further. Are you sure your PHP runs as CGI?
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.
> 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.
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.
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?
(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.
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.
*** Bug 62483 has been marked as a duplicate of this bug. ***
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.
*** Bug 60692 has been marked as a duplicate of this bug. ***
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.