[slurm-users] [External] Re: Invalid qos specification

[Prentice Bisbal]

That explanation makes perfect sense, but after adding debug to my list 
of QOSes in my associations, I still get the same error:

$ sacctmgr show user pbisbal withassoc -p
User|Def 
Acct|Admin|Cluster|Account|Partition|Share|MaxJobs|MaxNodes|MaxCPUs|MaxSubmit|MaxWall|MaxCPUMins|QOS|Def 
QOS|
pbisbal|unix|Administrator|pppl|unix||1|||||||dawson,debug,default,ellis,fenx,fielder,general,gque,greene,interactive,interruptible,jassby,kruskal,mccune,mque,normal,pswift,sque|general|
pbisbal|unix|Administrator|pppl|transp||1|||||||dawson,debug,ellis,general,interactive,kruskal,mccune,mque,normal|general|
pbisbal|unix|Administrator|test_pppl|transp||1|||||||dawson,debug,ellis,general,interactive,kruskal,mccune,mque,normal|general|
pbisbal|unix|Administrator|test_pppl|unix||1|||||||dawson,debug,default,ellis,fenx,fielder,general,gque,greene,interactive,interruptible,jassby,kruskal,mccune,mque,normal,pswift,sque|general|

And then:

$ salloc -p general -q qos -t 00:30:00
salloc: error: Job submit/allocate failed: Invalid qos specification

Prentice

On 7/15/19 2:55 PM, David Rhey wrote:
> I ran into this recently. You need to make sure your user account has 
> access to that QoS through sacctmgr. Right now I'd say if you did 
> sacctmgr show user <user> withassoc that the QoS you're attempting to 
> use is NOT listed as part of the association.
>
> On Mon, Jul 15, 2019 at 2:53 PM Prentice Bisbal <pbisbal at pppl.gov 
> <mailto:pbisbal at pppl.gov>> wrote:
>
>     Slurm users,
>
>     I have created a partition named general should allow the QOSes
>     'general' and 'debug':
>
>     PartitionName=general Default=YES AllowQOS=general,debug Nodes=.....
>
>     However, when I try to request that QOS, I get an error:
>
>     $ salloc -p general -q debug  -t 00:30:00
>     salloc: error: Job submit/allocate failed: Invalid qos specification
>
>     I'm sure I'm overlooking  something obvious. Any idea what that
>     may be?
>     I'm using slurm 18.08.8 on the slurm controller, and the clients are
>     still at 18.08.7 until tomorrow morning.
>
>     --
>     Prentice
>
>
>
>
> -- 
> 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/20190715/8cacbc73/attachment.htm>