Bug 14090

Can you verify that you're using mod_cgid instead of mod_cgi?

It works for me with mod_cgi, fails as you describe for me with mod_cgid.

Thanks,

Jeff

*** Bug 22672 has been marked as a duplicate of this bug. ***

Bug still exist in 2.4.08

Typo earlier on 2.0.48

*** Bug 15926 has been marked as a duplicate of this bug. ***

What ??

I dont know how my bug report got lumped into this one.

My report is about the contents of the ScriptLog....

If a cgi app emits to stderr....
aka 


puts stderr "hello world"


Mod_cgi's ScriptLog will catch that informations....
while mod_cgisd's ScriptLog will not!!!!

Please fix!

To fix, they would both involve a refactoring of how mod_cgid does its loging.
That is why I marked them as a duplicate.

*** Bug 35708 has been marked as a duplicate of this bug. ***

*** Bug 38398 has been marked as a duplicate of this bug. ***

Since comments #6 and #7 indicate general mod_cgid logging issues are being
recorded here, I have another one to add.  When writing to stderr and mod_cgi is
used, the error log includes the usual information specified for the output
format (e.g. time stamp, client IP address) before the output from the script,
but when doing the same through mod_cgid, it does not seem to include this
information, meaning the CGI stderr output is without a specific identifying
context.  (This is with 2.0.55 on NetBSD 3.0/i386, mod_cgi with the prefork MPM
and mod_cgid with the worker MPM.)

So with mod_cgi, we get (first row included for visual context):

[Tue Feb 28 05:34:28 2006] [error] [client 192.168.1.5] mod_mime_magic: can't
read `/usr/pkg/libexec/cgi-bin/errtest.cgi'
[Tue Feb 28 05:34:28 2006] [error] [client 192.168.1.5] This should be going to
the Apache error log.

And with mod_cgid, we get:

[Tue Feb 28 06:09:36 2006] [error] [client 192.168.1.5] mod_mime_magic: can't
read `/usr/pkg/libexec/cgi-bin/errtest.cgi'
This should be going to the Apache error log.

(Addendum to comment #10:) I've looked at the code for mod_cgid and see that the
Apache developers are aware of this, mod_cgid apparently doesn't have the
requisite information available to it.

I have just tested it on 2.2.6 and this bug is still present. Why is it marked
as RESOLVED?

(In reply to Artem Kuchin from comment #12)
> I have just tested it on 2.2.6 and this bug is still present. Why is it
> marked
> as RESOLVED?

I've just tested it with 2.4.7 and the bug is still present. 

But there are a simple way to fix it: disable mpm_event, enable cgi, enable mpm_event, and it works.

(In reply to Franz-Josef Huecker from comment #13)
> 
> I've just tested it with 2.4.7 and the bug is still present. 
> 
> But there are a simple way to fix it: disable mpm_event, enable cgi, enable
> mpm_event, and it works.

Sorry if this is a stupid question -- how exactly do you "disable mpm_event, enable cgi, enable mpm_event"?

I thought we could deal with the main error logging, but since the mod_cgid error logging does not including timestamps, on a very busy web server that hosts multiple domains, it's proven to be 99.9999% useless so far.

(In reply to wick from comment #14)
> (In reply to Franz-Josef Huecker from comment #13)
> > 
> > I've just tested it with 2.4.7 and the bug is still present. 
> > 
> > But there are a simple way to fix it: disable mpm_event, enable cgi, enable
> > mpm_event, and it works.
> 
> Sorry if this is a stupid question -- how exactly do you "disable mpm_event,
> enable cgi, enable mpm_event"?

I think this refers to some specific packaging loophole that would result in mod_cgi being used w/ event MPM,  instead of mod_cgid which is normally used with all threaded MPMs like event.

(In reply to Franz-Josef Huecker from comment #13)
> (In reply to Artem Kuchin from comment #12)
> > I have just tested it on 2.2.6 and this bug is still present. Why is it
> > marked
> > as RESOLVED?
> 
> I've just tested it with 2.4.7 and the bug is still present. 
> 
> But there are a simple way to fix it: disable mpm_event, enable cgi, enable
> mpm_event, and it works.

Thanks!

I spent several hours to understand what was going on until I could find this report.

Yes, I admit that I missed the line "Your MPM seems to be threaded. Selecting cgid instead of cgi."

I believe that in this case it is necessary to give an error message, and not enable another module (cgid instead cgi)

Is there an easy way in 2019 to write the error logs of each virtual host to the file specified in the virtual host configuration with mpm_event and cgid?

The not working way:
# a2dismod cgid
Module cgid disabled.

# a2enmod cgi
Your MPM seems to be threaded. Selecting cgid instead of cgi.
Enabling module cgid.


The working way:
# a2dismod mpm_event 
Module mpm_event disabled.

# a2dismod cgid
Module cgid disabled.

# a2enmod cgi
AH00534: apache2: Configuration error: No MPM loaded.
ERROR: Can't determine enabled MPMEnabling module cgi.
*Missing newline character in error message*

# a2enmod mpm_event 
Considering conflict mpm_worker for mpm_event:
Considering conflict mpm_prefork for mpm_event:
Enabling module mpm_event.

# apache2ctl -V
Server version: Apache/2.4.38 (Debian)
Server built:   2019-04-07T18:15:40
Server's Module Magic Number: 20120211:84
Server loaded:  APR 1.6.5, APR-UTIL 1.6.1
Compiled using: APR 1.6.5, APR-UTIL 1.6.1
Architecture:   64-bit
Server MPM:     event
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/etc/apache2"
 -D SUEXEC_BIN="/usr/lib/apache2/suexec"
 -D DEFAULT_PIDLOG="/var/run/apache2.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="mime.types"
 -D SERVER_CONFIG_FILE="apache2.conf"

Look here for a sugested patch by Joe Orton:

https://marc.info/?l=apache-httpd-dev&m=156337168604935&w=2

The patch is available for testing under

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

but the mail thread contains more details.

If it works well for you please report back here or to the httpd dev mailing list.

Thanks and regards,

Rainer