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@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
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@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
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@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
