[slurm-users] how to restrict jobs

navin srivastava navin.altair at gmail.com
Tue May 5 13:37:50 UTC 2020

Thanks Michael,

yes i have gone through but the licenses are remote license and it will be
used by outside as well not only in slurm.
so basically i am interested to know how we can update the database
dynamically to get the exact value at that point of time.
i mean query the license server and update the database accordingly. does
slurm automatically updated the value based on usage?


On Tue, May 5, 2020 at 7:00 PM Renfro, Michael <Renfro at tntech.edu> wrote:

> Have you seen https://slurm.schedmd.com/licenses.html already? If the
> software is just for use inside the cluster, one Licenses= line in
> slurm.conf plus users submitting with the -L flag should suffice. Should be
> able to set that license value is 4 if it’s licensed per node and you can
> run up to 4 jobs simultaneously, or 4*NCPUS if it’s licensed per CPU, or 1
> if it’s a single license good for one run from 1-4 nodes.
> There are also options to query a FlexLM or RLM server for license
> management.
> --
> Mike Renfro, PhD / HPC Systems Administrator, Information Technology
> Services
> 931 372-3601     / Tennessee Tech University
> > On May 5, 2020, at 7:54 AM, navin srivastava <navin.altair at gmail.com>
> wrote:
> >
> > Hi Team,
> >
> > we have an application whose licenses is limited .it scales upto 4
> nodes(~80 cores).
> > so if 4 nodes are full, in 5th node job used to get fail.
> > we want to put a restriction so that the application can't go for the
> execution beyond the 4 nodes and fail it should be in queue state.
> > i do not want to keep a separate partition to achieve this config.is
> there a way to achieve this scenario using some dynamic resource which can
> call the license variable on the fly and if it is reached it should keep
> the job in queue.
> >
> > Regards
> > Navin.
> >
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schedmd.com/pipermail/slurm-users/attachments/20200505/5d03623b/attachment.htm>

More information about the slurm-users mailing list