httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: un-macho serviceability aid for Unix MPMs
Date Wed, 03 Mar 2004 12:26:40 GMT
Joe Orton wrote:
> On Wed, Mar 03, 2004 at 06:34:06AM -0500, Jeff Trawick wrote:
>>This checks for a couple of common conditions which prevent core dumps from 
>>being taken and writes a NOTICE message to the error log at startup if the 
>>condition is detected.  BTW, the same code works with 1.3 with very minor 
>>tweaks (remove the apr_status_t parm from ap_log_error IIRC).
> I wrote a patch for a essentially the same feature recently: the common
> case is where the soft limit is set to zero but the hard limit is not;
> so iff CoreDumpDirectory is used, just raise the soft limit to the hard
> limit.

I was scared to raise the soft limit on core files, but I forgot about the 
presumed sanity of doing it if ap_coredumpdir_configured is set (just like 

 > +        if (getrlimit(RLIMIT_CORE, &lim) == 0 && lim.rlim_cur == 0) {
 > +            lim.rlim_cur = lim.rlim_max;
 > +            if (setrlimit(RLIMIT_CORE, &lim) == 0) {

In your patch, if the hard limit for core files is zero, there won't be a 
message, will there?

An odd case is Solaris where CoreDumpDirectory is not ordinarily necessary if 
coreadm is used to set the full path of core files.  In my patch the user would 
get a warning if ulimit is going to prohibit getting a core dump.

Another case where CoreDumpDirectory is not ordinarily necessary is when the 
server is started as non-root.  Yet it is still a problem if the core limit is 

I definitely prefer always reporting a missing CoreDumpDirectory if the server 
started as root.

I definitely prefer always reporting when the core limit is zero, root or not.

I can go either way on whether or not we attempt to raise the soft limit to
a *non-zero* hard limit when CoreDumpDirectory is specified.

Any other opinions?

View raw message