Ole Holm Nielsen <ole.h.niel...@fysik.dtu.dk> writes: > On 2/25/21 11:17 AM, Diego Zuccato wrote: >> Il 25/02/21 11:00, Ole Holm Nielsen ha scritto: >> >>> I think so, please see https://slurm.schedmd.com/resource_limits.html >>> and look for the MaxWallDurationPerJob limit. You have to set that >>> limit on the user's association. >> IIUC the limit in the assoc can't override the one in the partition. >> So the definition will have to be reversed: set the partition limit to >> the max allowed (1h) and limit all users except one in the assoc. > > You are right! According to the resource_limits page the limits have a > specified precedence. But now I see that there is an exception listed: > >> Note: The precedence order specified above is respected except for the >> following limits: Max[Time|Wall], [Min|Max]Nodes. For these limits, even if >> the job is enforced with QOS and/or Association limits, it can't go over the >> limit imposed at Partition level, even if it listed at the bottom. So the >> default for these 3 types of limits is that they are upper bound by the >> Partition one. This Partition level bound can be ignored if the respective >> QOS >> PartitionTimeLimit and/or Partition[Max|Min]Nodes flags are set, then the job >> would be enforced the limits imposed at QOS and/or association level >> respecting the order above.
Thanks for pointing that out, Ole. So I should be able to stop a user from submitting jobs by setting, say, MaxTime to 0, which is rather neater than tweaking the QOS. Cheers, Loris -- Dr. Loris Bennett (Hr./Mr.) ZEDAT, Freie Universität Berlin Email loris.benn...@fu-berlin.de
