[slurm-users] Drain a single user's jobs

David Rhey drhey at umich.edu
Wed Apr 1 12:19:49 UTC 2020


Hi Mark,

I *think* you might need to update the user account to have access to that
QoS (as part of their association). Using sacctmgr modify user <foo> + some
additional args (they escape me at the moment).

Also, you *might* have been able to set the MaxSubmitJobs at their account
level to 0 and have them run without having to do the QoS approach - but
that's just a guess on my end based on how we've done some things here. We
had a "free period" for our clusters and once it was over we set the
GrpSubmit jobs on an account to 0 which allowed in-flight jobs to continue
but no new work to be submitted.

HTH,

David

On Wed, Apr 1, 2020 at 5:57 AM Mark Dixon <mark.c.dixon at durham.ac.uk> wrote:

> Hi all,
>
> I'm a slurm newbie who has inherited a working slurm 16.05.10 cluster.
>
> I'd like to stop user foo from submitting new jobs but allow their
> existing jobs to run.
>
> We have several partitions, each with its own qos and MaxSubmitJobs
> typically set to some vaue. These qos are stopping a "sacctmgr update user
> foo set maxsubmitjobs=0" from doing anything useful, as per the
> documentation.
>
> I've tried setting up a competing qos:
>
>    sacctmgr add qos drain
>    sacctmgr modify qos drain set MaxSubmitJobs=0
>    sacctmgr modify qos drain set flags=OverPartQOS
>    sacctmgr modify user foo set qos=drain
>
> This has successfully prevented the user from submitting new jobs, but
> their existing jobs aren't running. I'm seeing the reason code
> "InvalidQOS".
>
> Any ideas what I should be looking at, please?
>
> Thanks,
>
> Mark
>
>

-- 
David Rhey
---------------
Advanced Research Computing - Technology Services
University of Michigan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schedmd.com/pipermail/slurm-users/attachments/20200401/a15d3f45/attachment.htm>


More information about the slurm-users mailing list