[slurm-users] Disable --no-allocate support for a node/SlurmD

René Sitt sittr at hrz.uni-marburg.de
Wed Jun 14 13:53:23 UTC 2023

Hello Alex,

I'd suggest taking a look at Slurm's Lua plugins for these kind of problems:


As far as I understand it, cli_filter.lua is geared towards controlling 
the use of specific commandline options, like the --no-allocate you 
mentioned (and the cli_filter.lua.example available in the Slurm sources 
shows how one can forbid the use of `srun --pty` - a classic way to 
start interactive jobs - for anyone except root).

job_submit.lua allows you to view (and edit!) all job parameters that 
are known at submit time, including the option to refuse a configuration 
by returning `slurm.ERROR`instead of `slurm.SUCCESS`. The common way to 
filter for interactive jobs in job_submit.lua is checking whether 
job_desc.script is nil or an empty string (i.e. the job submission 
doesn't have a script attached to it). You can do a lot more within 
job_submit.lua - I know of multiple sites (including the cluster I'm 
maintaining) that use it to, for example, automatically sort jobs into 
the correct partition(s) according to their resource requirements.

All in all, these two interfaces are (imho) much better suited for the 
kind of task you're suggesting (checking job parameters, refusing 
specific job configurations) than prolog scripts, since technically by 
the time the prolog scripts are starting, the job configuration has 
already been finalized and accepted by the scheduler.

Kind regards,
René Sitt

Am 14.06.23 um 15:03 schrieb Alexander Grund:
> Hi,
> we do some additional checking on a user and the batch script in a 
> Prolog script.
> However the `--no-allocate`/`-Z` bypasses allocation and hence 
> execution of the Prolog/Epilog.
> Is there a way to configure SlurmD to deny access to jobs without 
> allocations or more generally all interactive jobs?
> I know that only specific users are allowed to use `-Z` but 
> disallowing circumventing the Prolog on a specific node would provide 
> some additional safety as now that node would need to be breached first.
> Thanks,
> Alex
Dipl.-Chem. René Sitt
Hessisches Kompetenzzentrum für Hochleistungsrechnen
Philipps-Universität Marburg
35032 Marburg

Tel. +49 6421 28 23523
sittr at hrz.uni-marburg.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4239 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.schedmd.com/pipermail/slurm-users/attachments/20230614/e3d51055/attachment-0001.bin>

More information about the slurm-users mailing list