Fix RLIMIT_CORE hard limit #177
Conversation
exec_reaper() means to switch core dumps off for a job, but assigns
rlim_cur twice instead of assigning rlim_max once:
rlim.rlim_cur = 0;
rlim.rlim_cur = 0;
if (setrlimit(RLIMIT_CORE, &rlim) == -1)
rlim_max is therefore still the value left over from the RLIMIT_DATA
call three lines above, so the hard limit becomes the job's booked
memory instead of zero. A job can raise its soft limit again and dump a
core of that size into the working directory, which is the opposite of
what the code intends. Replicating the sequence for a job booked with
4096 MiB:
inherited RLIMIT_CORE soft=0 hard=42949672960
current: RLIMIT_CORE soft=0 hard=4294967296
fixed: RLIMIT_CORE soft=0 hard=0
Assign rlim_max, so that the limit is irrevocable for the job.
Fixes: 511439f ("mxqd: Enforce limits using setrlimit()")
Assisted-by: Claude Opus 5 (claude-opus-5)
|
This surly fixes the code to what was intended, but is it what we want? I can see that we want to prevent users from producing core files unintentionally, but core dumps have valid usages and we shouldn't forbid it if it is asked for explicitly. So maybe set the soft limit only and leave the hard limit as reported by getrlimit() ? btw: Currently we seem to have disabled core dumps globally (
|
Before commit 88d9aa4486863e888d489eb72cd4c21154abd588 there was a comment: 88d9aa4#diff-6055fef16441d98121b23582ef858437a0c22e1c31af49d47008601cece25f20L1055
Good question. I wasn’t able to find it. I always thought under
Probably not. |
We have and systemd does the rest: |
|
Oh dear, that code is a bit surprising. Next question would be why our systemd package masks the file. It's not explicit in the bee file. Maybe |
I think to remember to have masked it in 2018 directly on the distmaster. You are right, that it should be moved to mxtools. |
|
"why our systemd package masks the file" : I confused the wild file |
For yet unknown reason, when a command ist started with sudo, it has core hard and soft limit 0. So when mxqd is started with "sudo", its soft limit is also 0. So it currently doesn't make a difference whether we set the soft limit to or leave it as is (undefined, maybe 0). |
sudoers(5):
We currently don't have |
2 participants
Found by claude-opus-5 while working on something else.
Resolves: #183