What happens
A partition configured with DefaultTime = "00:00:00" (or "0") gives a job submitted without -t a zero-length time limit. parse_time_minutes maps "00:00:00" to Some(0), and apply_default_time_limit treats that as a usable default and assigns it, so the job is admitted with TimeLimit=00:00:00.
Verified against the real code path with a throwaway probe over apply_default_time_limit:
DefaultTime=00:00:00 parses to Some(0), job time_limit becomes Some(TimeDelta { secs: 0, nanos: 0 })
What was expected
Slurm rejects the submission in exactly this case. From _valid_job_part() in src/slurmctld/job_mgr.c:
if ((job_desc->time_limit == NO_VAL) &&
(part_ptr->default_time == 0)) {
info("%s: job's default time is 0", __func__);
rc = ESLURM_INVALID_TIME_LIMIT;
goto fini;
}
Note this is specific to DefaultTime being explicitly 0; an unset DefaultTime (NO_VAL) is admitted by Slurm and is not what this issue is about.
Worth deciding as part of this: whether a 0 here should mean "reject", "no default" (as maxwall = 0 already means block-all elsewhere in Spur), or something else, and whether the same reasoning applies to MaxTime = 0 and to scheduler.default_time_limit_minutes, which uses 0 as its "unset" sentinel.
Reproduction
[[partitions]]
name = "zero"
default = true
nodes = "ALL"
default_time = "00:00:00"
# no -t
sbatch --wrap 'sleep 60'
scontrol show job <id> # TimeLimit=00:00:00
Impact
A job admitted with a zero-length limit has a deadline at or before its own start, so the running-job watchdog is entitled to kill it immediately. Every -t-less submission to such a partition is accepted and then killed, instead of being refused at submit with a clear error. The misconfiguration is silent from the submitter's side.
Notes
Found while reviewing the MaxWall defaulting work in #728 (the wall-time default chain is where the zero reaches the job). Unrelated to that PR's change and deliberately not folded into it.
What happens
A partition configured with
DefaultTime = "00:00:00"(or"0") gives a job submitted without-ta zero-length time limit.parse_time_minutesmaps"00:00:00"toSome(0), andapply_default_time_limittreats that as a usable default and assigns it, so the job is admitted withTimeLimit=00:00:00.Verified against the real code path with a throwaway probe over
apply_default_time_limit:What was expected
Slurm rejects the submission in exactly this case. From
_valid_job_part()insrc/slurmctld/job_mgr.c:Note this is specific to
DefaultTimebeing explicitly0; an unsetDefaultTime(NO_VAL) is admitted by Slurm and is not what this issue is about.Worth deciding as part of this: whether a
0here should mean "reject", "no default" (asmaxwall = 0already means block-all elsewhere in Spur), or something else, and whether the same reasoning applies toMaxTime = 0and toscheduler.default_time_limit_minutes, which uses0as its "unset" sentinel.Reproduction
Impact
A job admitted with a zero-length limit has a deadline at or before its own start, so the running-job watchdog is entitled to kill it immediately. Every
-t-less submission to such a partition is accepted and then killed, instead of being refused at submit with a clear error. The misconfiguration is silent from the submitter's side.Notes
Found while reviewing the
MaxWalldefaulting work in #728 (the wall-time default chain is where the zero reaches the job). Unrelated to that PR's change and deliberately not folded into it.