On 7 Jul 2016, at 04:20, Jakob Hirsch <jh@plonk.de> wrote:
Alan DeKok wrote on 2016-07-06 15:13:
Tue Jul 5 13:16:42 2016 : Error: Cannot update core dump limit: Operation not permitted Tue Jul 5 13:16:42 2016 : Info: Core dumps are enabled Tue Jul 5 13:16:42 2016 : Info: Debugger not attached Any idea what's going wrong here? The server is probably changing UID, and trying to update the core limit after that.
I guess that's not a problem (since FR does a prctl(PR_SET_DUMPABLE, 1) after the UID/GID changes):
setgroups(1, [106]) = 0 setgid(106) = 0 mkdir("/var/log/freeradius", 0700) = -1 EEXIST (File exists) geteuid() = 0 setresuid(4294967295, 104, 0) = 0 geteuid() = 104 setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=0}) = 0 open("/var/log/freeradius/radius.log", O_WRONLY|O_CREAT|O_APPEND, 0640) = 3 fchown(3, 104, 106) = 0 prctl(PR_SET_DUMPABLE, 1) = 0 setrlimit(RLIMIT_CORE, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = -1 EPERM (Operation not permitted)
but FR uses setrlimit() with rlim_max=0, and you can only lower rlim_max, but not raise it (unless you have the CAP_SYS_RESOURCE capability).
OK... So there's probably an issue there. Could we get the stack trace so it's clear what logic is being executed. There's only two calls to setrlimit in the server...
I don't know what the call setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=0}) is good for...
It disables core dumping. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2