Jeff Trawick wrote:
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 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?
I would be inclined to raise the soft limit if CoreDumpDirectory is set and log a message that it had been done. I'm a big believer in letting the user know if you automagically do something "for" them. The log entry would let them know that they need to remove CoreDumpDirectory if they don't want this.
I would also be inclined to log a message if core limit is zero, root or not, so that we have predictable behavior (regardless of the platform). It would add a level of uncertainty if it didn't since we would have to ask, "Is this Solaris (or some other system with similar behavior) and is there a value set in coreadm for core files?"
So I guess I'd recommend something like:
static void check_dumpable(server_rec *s)
{
struct rlimit rl;
int rc;
int already_complained = 0; rc = getrlimit(RLIMIT_CORE, &rl);
if (rc == 0) {
if (ap_coredumpdir_configured) {
if ((rl.rlim_cur == 0) && (rl.rlim_max > 0)) {
rl.rlim_cur = rl.rlim_max;
ap_log_error (APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE, 0, s,
"Soft limit for core files raised to hard limit of (%d)"
" since CoreDumpDirectory is set.",
rl.rlim_max);
}
else if (rl.rlim_max == 0) {
ap_log_error (APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE, 0, s,
"Despite the user specified CoreDumpDirectory value,"
" core files cannot be created since hard limit is 0.");
}
/* Do we want to be *really* motherly? */
else if ((rl.rlim_cur > 0) && (rl.rlim_max > 0)) {
ap_log_error (APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE, 0, s,
"Potential core files to be stored at %s",
ap_coredump_dir);
}
}
else {
if (rl.rlim_max == 0) {
ap_log_error (APLOG_MARK, APLOG_NOTICE, 0, s,
"Core files cannot be created since hard limit is 0.");
}
else if (geteuid() == 0) {
ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE, 0, s,
"CoreDumpDirectory not set; core dumps may not be written
for"
" child process crashes");
}
}
}
}-- Paul J. Reder ----------------------------------------------------------- "The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure." -- Albert Einstein
