Enrik Berkhan wrote:
when coredumps are enabled in the config file, the code in mainconfig.c does an setrlimit(RLIMIT_CORE, ...) using the core limits retrieved by an earlier getrlimit(RLIMIT_CORE, ...). This looks useless to me.
It's there for paranoia. Maybe the limits get reset after setuid().
I think the original intention of the setrlimit() was to actually enable core dumping in case the server is started with core dump limit set to 0 but coredumps enabled in the config file.
No. If the parent shell has the core limit set to zero, the server should respect that.
Further, a prctl() call to set the dumpable flag of the process is protected by HAVE_SYS_PRTCL_H which should be HAVE_SYS_PRCTL_H. Even
Fixed.
with the typo fixed, the code will never be run, because configure does not check for prctl.h yet.
I can go fix that, too.
I have attached a suggested patch (not including configure / prctl.h).
I've committed some code clarifying the code paths, and doing additional checks: - if debug_flag > 0, core dumps are always allowed (ulimit inherited from parent shell) - if NOT debugging AND core dumps are disabled, AND we didn't do setuid(), then disable core dumps. (setuid disables core dumps by itself) - if we're in daemon mode, AND core dumps are enabled, AND we did setuid(), then re-enable core dumps. - otherwise, core limit is inherited from parent process. Alan DeKok.