In `exec_reaper()` the same field is assigned twice, so the RLIMIT_CORE **hard** limit keeps whatever the preceding RLIMIT_DATA block left in it: https://github.molgen.mpg.de/mariux64/mxq/blob/master/mxqd.c#L1027 ```c rlim.rlim_cur = group->job_memory*1024*1024; rlim.rlim_max = group->job_memory*1024*1024; if (setrlimit(RLIMIT_DATA, &rlim) == -1) mx_log_err(...); rlim.rlim_cur = 0; rlim.rlim_cur = 0; /* <-- should be rlim.rlim_max = 0; */ if (setrlimit(RLIMIT_CORE, &rlim) == -1) mx_log_err(...); ``` So the job is started with core soft limit 0 but hard limit `job_memory * 1024 * 1024`. ### Impact The soft limit is only advisory against the process itself: any job may call `setrlimit(RLIMIT_CORE, ...)` and raise its soft limit back up to the hard limit, then dump a core file of up to `job_memory` bytes into its working directory. For a `-m 956G` job that is a 956 GB core file on a shared filesystem. Zeroing the hard limit — clearly the intent here — is what makes it unraisable. ### Suggested fix ```c rlim.rlim_cur = 0; rlim.rlim_max = 0; ``` --- Found during an assisted code review of the whole code base (Claude Opus 5 via Claude Code). **Not reproduced at runtime** — read directly from the source; the duplicated line is unambiguous. I did not submit a job that raises its own core limit to demonstrate it.