[gridengine users] Error: job is not allowed to run in any queue

Reuti reuti at Staff.Uni-Marburg.DE
Wed Jul 29 18:07:38 UTC 2015


Hi,

Am 29.07.2015 um 19:45 schrieb John Lilley:

> Thanks for the explanation Reuti. Hoping I didn’t misunderstand something so I ran...
> 
> qconf -aq dummyqueue
> sudo qconf -mq dummyqueue (and changed slots to 0) 
> 
> then 
> 
> qsub testjob.sub
> or
> qsub -w n testjob.sub
> 
> [ec2-user at ip-172-31-x-xxx ~]$ qsub test.sub (gets submitted to the default all.q)
> Unable to run job: warning: ec2-user's job is not allowed to run in any queue
> Your job 11 ("test.sub") has been submitted
> Exiting.
> 
> 
> and then tried...
> 
> [ec2-user at ip-172-31-x-xxx ~]$ qsub -l q='dummyqueue' test.sub (specified the dummyqueue which I planned to add as default to sge_request using -q dummyqueue)
> Unable to run job: warning: ec2-user's job is not allowed to run in any queue
> Your job 11 ("test.sub") has been submitted
> Exiting.
> 
> 
> Additional information: 
> 
> [root at ip-172-31-x-xxx ~]# qconf -sql 
> all.q
> dummyqueue
> 
> 
> [root at ip-172-31-x-xxx ~]# qconf -sq all.q | grep -e slot -e host
> hostlist              @allhosts
> slots                 1
> 
> [root at ip-172-31-x-xxx ~]# qconf -sq dummyqueue | grep -e slot -e host
> hostlist              NONE

No, the headnode itself should appear here (as only entry).



> slots                 0
> 
> 
> 
> 
> I attempted again after adding the hostgroup @allhosts to the dummyqueue with 0 slots but ran into same error when submitting to either queue when 0 compute instances present. 
> 
> [root at ip-172-31-x-xxx ~]# qconf -sq dummyqueue | grep -e slot -e host
> hostlist              @allhosts
> slots                 0
> 
> 
> [ec2-user at ip-172-31-x-xxx ~]$ qsub  test.sub 
> Unable to run job: warning: ec2-user's job is not allowed to run in any queue
> Your job 14 ("test.sub") has been submitted
> Exiting.
> [ec2-user at ip-172-31-x-xxx ~]$ qdel 14
> ec2-user has deleted job 14
> [ec2-user at ip-172-31-x-xxx ~]$ qsub -l q='dummyqueue' test.sub 

It shouldn't be necessary to do it this way ("dummyqueue" is the only one). In case you want to request any queue: "-q <qname>" may be more straight forward.

-- Reuti


> Unable to run job: warning: ec2-user's job is not allowed to run in any queue
> Your job 15 ("test.sub") has been submitted
> Exiting.
> [ec2-user at ip-172-31-x-xxx ~]$ qdel 15
> ec2-user has deleted job 15
> [ec2-user at ip-172-31-x-xxx ~]$ 
> 
> 
> [ec2-user at ip-172-31-x-xxx ~]$ qconf -shgrp @allhosts
> group_name @allhosts
> hostlist NONE
> 
> 
> 
> 
> 
> 
> 
> 
> On 7/28/15, 1:58 PM, "Reuti" <reuti at staff.uni-marburg.de> wrote:
> 
>> Hi,
>> 
>> Am 28.07.2015 um 19:38 schrieb John Lilley:
>> 
>>> Hi William, 
>>> 
>>> 
>>> Yeah, I tried that and it appeared to have no effect on the error 
>>> received. I did a -w e to see if it prevented the job from running in 
>>> order to test if the command line parameters were even being read in and 
>>> it looks like they are as the job was not allowed to run. 
>>> 
>>> [johnbot at ip-172-31-3-22 ~]$ qhost
>>> HOSTNAME                ARCH         NCPU NSOC NCOR NTHR  LOAD  MEMTOT  
>>> MEMUSE  SWAPTO  SWAPUS
>>> ---------------------------------------------------------------------------
>>> -------------------
>>> global
>>> 
>>> 
>>> [johnbot at ip-172-31-x-xx ~]$ qsub -w n sleep.sub
>>> Unable to run job: warning: johnbot's job is not allowed to run in any 
>>> queue
>>> Your job 319 ("johnbot-sleep") has been submitted
>>> Exiting.
>>> [johnbot at ip-172-31-x-xx ~]$ qdel 319
>>> johnbot has deleted job 319
>>> [johnbot at ip-172-31-x-xx ~]$ qsub -w e sleep.sub
>>> Unable to run job: warning: johnbot's job is not allowed to run in any 
>>> queue
>>> error: no suitable queues
>>> Exiting.
>>> 
>>> 
>>> I also added -w n to the sge installation directories' sge_request file 
>>> and finally ~/.sge_request as mentioned here: 
>>> http://gridscheduler.sourceforge.net/htmlman/htmlman5/sge_request.html . 
>>> Setting other options in those two files does effect job submission as 
>>> when done manually with qsub above so they are definitely being read in. 
>>> Not sure what to try next. 
>> 
>> The above message may appear either because of a set user_lists attribute in all of the queues, or in case there is no queue at all, or only queues with an empty hostlist exist (i.e. no queue instance).
>> 
>> AFAICS it can't be suppressed by any flag.
>> 
>> Well, the idea in SGE was too, that it should be possible to submit a job with a request for resources which are only available in the future (like submitting with a high memory request, which will become available only once new nodes are set up). OTOH requesting a non-existing queue should be prohibited, and requesting an unknown queue throws a different error, but can't be suppressed too.
>> 
>> As the the qmaster is running in your set up: what about a dummy queue which runs on the qmaster itself, but has zero slots? The "no suitable queues" warning won't appear by default (unless "-w w" or "-w e " is set).
>> 
>> -- Reuti
>> 
>> PS: Sure: changing daemons/qmaster/sge_job_verify.c by changing/removing the "first check user permissions" block might help too.
>> 
>> 
>>> On 7/28/15, 12:12 AM, "William Hay" <w.hay at ucl.ac.uk> wrote:
>>> 
>>>> On Tue, 28 Jul 2015 00:48:17 +0000
>>>> John Lilley <johnbot at syntaxerror.io> wrote:
>>>> 
>>>> 
>>>>> I should add that the jobs do complete fine but it would be better if
>>>>> submitting jobs didn’t trigger the error.
>>>>> 
>>>>> [user at ip-172-50-32-1 ~]$ qsub sleep.sub
>>>>> Unable to run job: warning: users's job is not allowed to run in any
>>>>> queue Your job 51 (“user-sleep") has been submitted
>>>>> Exiting.
>>>> Does qsub -w n shut it up?  In theory it is the default but this may
>>>> have been overridden somewhere to set it to -w w.  Unless that
>>>> somewhere is a jsv then the command line should be definitive.
>>>> 
>>>> William
>>>> 
>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> users mailing list
>>> users at gridengine.org
>>> https://gridengine.org/mailman/listinfo/users
>>> 
>> 
> 





More information about the users mailing list