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@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@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@ip-172-31-x-xxx ~]# qconf -sql
all.q
dummyqueue
[root@ip-172-31-x-xxx ~]# qconf -sq all.q | grep -e slot -e host
hostlist @allhosts
slots 1
[root@ip-172-31-x-xxx ~]# qconf -sq dummyqueue | grep -e slot -e host
hostlist NONE
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@ip-172-31-x-xxx ~]# qconf -sq dummyqueue | grep -e slot -e host
hostlist @allhosts
slots 0
[ec2-user@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@ip-172-31-x-xxx ~]$ qdel 14
ec2-user has deleted job 14
[ec2-user@ip-172-31-x-xxx ~]$ qsub -l q='dummyqueue' test.sub
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@ip-172-31-x-xxx ~]$ qdel 15
ec2-user has deleted job 15
[ec2-user@ip-172-31-x-xxx ~]$
[ec2-user@ip-172-31-x-xxx ~]$ qconf -shgrp @allhosts
group_name @allhosts
hostlist NONE
On 7/28/15, 1:58 PM, "Reuti" <[email protected]> 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@ip-172-31-3-22 ~]$ qhost
>> HOSTNAME ARCH NCPU NSOC NCOR NTHR LOAD MEMTOT
>> MEMUSE SWAPTO SWAPUS
>> ---------------------------------------------------------------------------
>> -------------------
>> global
>>
>>
>> [johnbot@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@ip-172-31-x-xx ~]$ qdel 319
>> johnbot has deleted job 319
>> [johnbot@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" <[email protected]> wrote:
>>
>>> On Tue, 28 Jul 2015 00:48:17 +0000
>>> John Lilley <[email protected]> wrote:
>>>
>>>
>>>> I should add that the jobs do complete fine but it would be better if
>>>> submitting jobs didn’t trigger the error.
>>>>
>>>> [user@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
>> [email protected]
>> https://gridengine.org/mailman/listinfo/users
>>
>
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
