[slurm-users] Disable Account Limits Per Partition?

Ryan Cox ryan_cox at byu.edu
Thu Feb 22 14:25:59 MST 2018


I'm not sure about accounts but you can do that with users:
sacctmgr add user someuser823 account=myaccount7 partition=somepartition

You can set different limits for particular partitions (grpsubmit example):
sacctmgr modify user someuser823 partition=somepartition set grpsubmit=10000
sacctmgr modify user someuser823 partition=somepartition set 
grpsubmit=-1 #unset limit

Limits are per *association* where an association is the combination of 
cluster, account, user, and partition.  Partition is optional.

If you want to figure something out for accounts or for everyone, you 
probably want to look at using a QOS to override the limits and control 
access to the partitions.  Maybe even a partition QOS.


On 02/21/2018 02:13 PM, Roberts, John E. wrote:
> Hi,
> I'm not sure of the best way to solve this and I don't see any obvious things I can set in the configuration. Please let me know if I'm missing something.
> I have several partitions in Slurm (16.05). I also have many accounts with users tied to them and all of the accounts have a CPU hour limit of some number. Accounting Enforcement is set to 'safe' so users can't submit jobs unless they have time.
> The problem I'm running into is that I also have a few partitions that shouldn't charge for time. I have this set on them: TRESBillingWeights="CPU=0.0". This works in that at the end of the job they don't get charged for the hours, however, they can't start the job unless they have the time initially. I'd like for them to be able to submit to these partitions with any account even if the account has run out of hours. I'd also like to avoid creating "special" accounts with a ton of hours just to get them running as well. This doesn't work well with how we grant hours and track things, but certainly will do this if it's my only option.
> Any advice?
> --
> Thanks.
> John

Ryan Cox
Operations Director
Fulton Supercomputing Lab
Brigham Young University

More information about the slurm-users mailing list