Yes - this is with suexec - quite possibly adding mayhem. But the problem
encountered is a regression, the old cgid would fail under load for a few requests,
and then resume it's happy existence. Now cgid is dying absolutely with a
SIGPIPE failure (which should have been trapped according to the parent's
signal mask???). Again, this is a very heavy load scenario.
Sander Temme attached GDB to the CGId process and prodded it until
it crashed here:
(gdb) continue
Continuing.
[New Thread 1 (LWP 1)]
[Switching to Thread 1 (LWP 1)]
Program received signal SIGPIPE, Broken pipe.
0x3c7a0 in log_error_core ()
(gdb) bt
#0 0x3c7a0 in log_error_core ()
#1 0x3cb0c in ap_log_error ()
#2 0xfe7b3228 in cgid_server ()
from /local0/sctemme/inst/ersN14/apache/modules/standard/mod_cgid.so
#3 0xfe7b35e4 in cgid_init ()
from /local0/sctemme/inst/ersN14/apache/modules/standard/mod_cgid.so
#4 0x3badc in ap_run_post_config ()
#5 0x3e10c in main ()
Without load you might see no side effects. Sander was using specweb99
but you might also try ab(using) a valid printenv script, with 40 concurrent
connections or so. You might even throw in a sleep(2) into that script just
to increase the chances of overload.
Remember that we've already run the child_cleanups, so all uninherited
files are closed upfront. If you want to leave one dangling file hanging
around, you remember this patch;
--- log.c 15 Feb 2003 01:21:31 -0000 1.127.2.2
+++ log.c 20 Mar 2003 21:56:06 -0000 1.127.2.3
@@ -320,8 +320,6 @@
ap_server_argv0, fname);
return DONE;
}
-
- apr_file_inherit_set(s->error_log);
}
return OK;
So if we call apr_file_inherit_set(r->server->error_log) in the cgid daemon
to ensure we can log as you've attempted to do, and immediately call
apr_file_inherit_unset(r->server->error_log) when finished with that one
request, this could solve the problem.
But I still suspect it would be better to either print the error exception
to something predictable like stderr, or create a 500 response in the
forked cgid exec process itself to stdout, with perhaps an apache-private
header (e.g. x-httpd-logerror: foo) that will be shuttled to the log file and
removed before sending the response to the client.
Bill
At 09:25 PM 3/28/2003, Jeff Trawick wrote:
>Jeff Trawick wrote:
>
>>Let me try it with your latest tag on Solaris 8 and see if my results are any
>>different.
>
>Solaris 8, your _RC2 tag, worker+mod_cgid or prefork+mod_cgid:
>
>[Fri Mar 28 21:43:07 2003] [debug] prefork.c(1039): AcceptMutex: posixsem (default:
>posixsem)
>[Fri Mar 28 21:43:10 2003] [error] (13)Permission denied: exec of 'printenv' failed
>[Fri Mar 28 21:43:10 2003] [error] [client 127.0.0.1] Premature end of script
>headers: printenv
>
>[Fri Mar 28 22:04:55 2003] [debug] worker.c(1736): AcceptMutex: posixsem (default:
>posixsem)
>[Fri Mar 28 22:04:58 2003] [error] (13)Permission denied: exec of 'printenv' failed
>[Fri Mar 28 22:04:58 2003] [error] [client 127.0.0.1] Premature end of script
>headers: printenv
>
>Here's the set of modules I have:
>
>Compiled in modules:
> core.c
> mod_access.c
> mod_auth.c
> mod_file_cache.c
> mod_charset_lite.c
> mod_case_filter.c
> mod_case_filter_in.c
> mod_ext_filter.c
> mod_include.c
> mod_log_config.c
> mod_env.c
> mod_mime_magic.c
> mod_expires.c
> mod_headers.c
> mod_usertrack.c
> mod_unique_id.c
> mod_setenvif.c
> worker.c
> http_core.c
> mod_mime.c
> mod_dav.c
> mod_status.c
> mod_autoindex.c
> mod_asis.c
> mod_info.c
> mod_cgid.c
> mod_dav_fs.c
> mod_vhost_alias.c
> mod_negotiation.c
> mod_dir.c
> mod_imap.c
> mod_actions.c
> mod_userdir.c
> mod_alias.c
> mod_rewrite.c
> mod_so.c
>
>nothing loaded dynamically
>
>Maybe you want to use truss to see which file descriptor leads to SIGPIPE, and then
>back up to see approx. where it was closed?
>
>Maybe not catching SIGPIPE in this short path is a good thing after all.
>
