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 prctl()).
> + 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 zero.
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?
