httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Apache 1.3.28 SEGFAULTS and doesn't produce a core file
Date Tue, 02 Dec 2003 01:32:56 GMT
On Mon, 1 Dec 2003, Jeff Trawick wrote:

> FWIW, it segfaults on a jsp request...  I suppose that this is handled by a
> third party module such as mod_jk?  See the final snippet:

We are using the BEA weblogic plugin to broker *.jsp to our application
server. We are using the latest QE'ed build of the plugin.

> [pid 32119] read(11, "GET /messaging/businessObject.js"..., 4096) = 775
> [pid 32119] rt_sigaction(SIGUSR1, {SIG_IGN}, {0x4002127c, [],
> SA_INTERRUPT|0x4000000}, 8) = 0
> [pid 32119] time(NULL)                  = 1069347777
> [pid 32119] stat64("/etc/httpd/htdocs/email/messaging/businessObject.jsp",
> {st_mode=S_IFREG|0644, st_size=12754, ...}) = 0
> [pid 32119] getpid()                    = 32119
> [pid 32119] getpid()                    = 32119
> [pid 32119] --- SIGSEGV (Segmentation fault) ---
> [pid 10610] wait4(-1, [WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV], WNOHANG,

We are also using auth_ldap to authenticate users, and authentication
looks to be occuring right before the programs SEGFAULTS. Since I cannot
associate the getpid()'s with a module, I cannot pinpoint which module is
causing Apache grief.

> Common issues with getting coredumps from Apache 1.3 on Linux 2.4 kernel:
> 1) prctl() call, resolved by mod_prctl or patch like that posted on the list

Even with the prtctl module Apache refuses to dump core. Once I start
Apache as the user "apache," it dumps core perfectly. It looks like
the Linux kernel refuses to let any program that changes it's uid
core. I wish this option could be disabled through "/proc" or sysctl
until I get a core to analyze.

> 2) ulimit -c setting in the shell used to start Apache

Our ulimits are cool.

> 3) CoredumpDirectory directive MUST BE SPECIFIED and must point to a directory
> that the web server user id (e.g., "nobody") has write access to; additionally,
> there must be plenty of free space in that directory; without the
> CoredumpDirectory, the default directory (serverroot) will be used, and the web
> server user id doesn't have write access there

Got all three of these items taken care of.

> Check #3 in particular.  I don't think it was mentioned in the responses to
> your post.
> Another thing: To verify that the problem with core dump is not your
> system/Apache configuration but instead something horrible that happens due to
> the way the child process crashes, send SIGSEGV to some random child process*
> and verify that the kernel is able to write a coredump and that the message
> written to the Apache error log has "possible coredump in /some/dir" as part of
> the "child pid XXX exit signal YYY" message
> *obviously you may not want to do that if the server is in production :)

Thanks for your feedback. I am going to reconfigure my web servers to
start Apache as a non-root user, and run the web servers on port 8000.
Since we have a pair of load-balancers in front of the web servers, this
shoulnd't cause use too much grief.

View raw message