Reuti, Thanks for the great workaround, worked like a charm.
John On 7/29/15, 11:07 AM, "Reuti" <[email protected]> wrote: >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
