[GE users] Consumable complex not being consumed?

Daire Byrne Daire.Byrne at framestore-cfc.com
Mon Jun 11 16:18:00 BST 2007


    [ The following text is in the "utf-8" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some characters may be displayed incorrectly. ]

Daniel,

----- "Daniel Templeton" <Dan.Templeton at Sun.COM> wrote:
> You're using the BOOL syntax when requesting an INT consumable.  You 
> have to give it the number of licenses that you want, like Andy and 
> Reuti said.  I'm actually surprised that you're not seeing more of an

Sorry for the confusion, I think you are referring to the incomplete command I used in the last email. Am in fact using "-hard -l license_mayaU=1". It's really bugging me now - I have tried restarting all daemons etc. but no change. I think I may have to resort to a complete reinstall from scratch. The license complex works fine in that it correctly blocks jobs when there is not enough licenses available - but the automatic decrement/increment (i.e. consumable) attribute is being ignored.

The only slightly non-standard thing about my setup is that /opt/sge/default/common is a symlink via NFS to the Qmaster server on all exec hosts. And then /opt/sge/default/spool dirs are local on all machines. I see no reason why this should be related to my problem.

Regards,

Daire

> error.  The code in the qmaster looks like it's supposed to treat a 
> valueless INT consumable as an error.
> 
> Daniel
> 
> Andy Schwierskott wrote:
> > Daire,
> >
> > I can confirm was Reuti was saying. After submitting the job
> >
> >   qsub -hard -l license_mayaU=1 ....
> >
> > everything works as expected. I had the counters set to 0 first, 
> > submitted
> > the jobs and then increased the counter of one attribute to 10 in
> the 
> > global
> > host config.
> >
> > I tried it with 6.0u10.
> >
> > Andy
> >
> >> Reuti,
> >>
> >> Well I've tried deleting the complexes and recreating them but
> still 
> >> no joy. Here's the commands used to create the complexes:
> >>
> >> qconf -mc (then add the following)
> >> license_mayaC       l_mC       INT         <=    YES         
> >> YES        0        0
> >> license_mayaT       l_mT       INT         <=    YES         
> >> YES        0        0
> >> license_mayaU       l_mU       INT         <=    YES         
> >> YES        0        0
> >>
> >> qconf -mattr exechost complex_values 
> >> license_mayaC=0,license_mayaT=0,license_mayaU=0 global
> >>
> >> Then I give one of the licenses some value and submit a job with 
> >> "-hard -l license_mayaU" (say) and I see that the total count is 
> >> unchanged while the job runs or quits. Perhaps I can turn up the 
> >> debugging to see where things are failing? There is nothing of 
> >> interest in any of the "messages" files as far as I can make out.
> >>
> >> I haven't found anything else wrong with installation - just 
> >> consumables for now. I've not had this issue before so I'm not
> ruling 
> >> out a bad install on my part. Any more info I can give?
> >>
> >> Regards,
> >>
> >> Daire
> >>
> >> ----- "Reuti" <reuti at staff.uni-marburg.de> wrote:
> >>> Am 08.06.2007 um 17:09 schrieb Daire Byrne:
> >>>
> >>>> Reuti,
> >>>>
> >>>>> what is:
> >>>>>
> >>>>> qhost -F license_mayaT
> >>>>>
> >>>>> showing?
> >>>>
> >>>> Typical output is:
> >>>>
> >>>> HOSTNAME                ARCH         NCPU  LOAD  MEMTOT  MEMUSE
> >>>> SWAPTO  SWAPUS
> >>>>
> >>>
> ----------------------------------------------------------------------
> >>>
> >>>> ---------
> >>>> global                  -               -     -       -
> >>>> -       -       -
> >>>>     Host Resource(s):      gc:license_mayaT=5.000000
> >>>> lust1b.prod.local       lx24-amd64      2  0.24    5.8G    2.2G
> >>>
> >>>> 2.0G    8.0K
> >>>>     Host Resource(s):      gc:license_mayaT=5.000000
> >>>>
> >>>> etc. for all hosts. It definitely there as asking for 6 licenses
> >>>> blocks the job from running. But once it does run the value
> remains
> >>>
> >>>> the same. Maybe I should just try recreating the complex?
> >>>
> >>> I don't see this, for me it's perfectly working - even if I create
> a
> >>>
> >>> complex with name license_mayaT (also SGE 6.1). - Reuti
> >>>
> >>>
> >>>> Regards,
> >>>>
> >>>> Daire
> >>>>
> >>>>
> >>>> ----- "Reuti" <reuti at staff.uni-marburg.de> wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Am 08.06.2007 um 16:25 schrieb Daire Byrne:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I setup some consumable complexes for licenses but they aren't
> >>>>>> getting decremented when a job requests a "license".
> >>>>>>
> >>>>>> # qconf -sc | grep license
> >>>>>> #name               shortcut   type        relop requestable
> >>>>>> consumable default  urgency
> >>>>>>
> >>>>>
> >>>
> #--------------------------------------------------------------------
> >>>
> >>>>> -
> >>>>>
> >>>>>> --------------------
> >>>>>> license_mayaC       l_mC       INT         <=    YES
> >>>>>> YES        0        0
> >>>>>> license_mayaT       l_mT       INT         <=    YES
> >>>>>> YES        0        0
> >>>>>> license_mayaU       l_mU       INT         <=    YES
> >>>>>> YES        0        0
> >>>>>>
> >>>>>> # qconf -se global | grep license
> >>>>>> license_mayaC=0,license_mayaT=5,license_mayaU=5
> >>>>>>
> >>>>>> If I submit a job using:
> >>>>>>   qrsh -V -now n -q qapp.q -l
> hostname=$HOSTNAME,license_mayaT=5
> >>> -b
> >>>>>
> >>>>>> y glxgears
> >>>>>>
> >>>>>> Checking with "qconf -se" I still have license_mayaT=5
> >>> afterwards.
> >>>>>
> >>>>>> It's not being "consumed". Have I missed a config option
> >>> somewhere?
> >>>>>
> >>>>>> If I request license_mayaT=6 the job doesn't run because I
> >>> haven't
> >>>>>
> >>>>>> got enough licenses which suggests SGE is recognising the
> complex
> >>>>>> just not consuming it while the job is running. I am using SGE
> >>> 6.1
> >>>>>
> >>>>>> on a mix of x86 and x86_64 servers/clients. This used to work
> for
> >>>>>> me last time I installed and configured SGE - have I found a
> bug?
> >>>>>
> >>>>> what is:
> >>>>>
> >>>>> qhost -F license_mayaT
> >>>>>
> >>>>> showing?
> >>>>>
> >>>>> -- Reuti
> >>>>>
> >>>>>
> >>>
> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail:
> users-unsubscribe at gridengine.sunsource.net
> >>>>> For additional commands, e-mail:
> >>> users-help at gridengine.sunsource.net
> >>>>
> >>>>
> >>>
> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail:
> users-unsubscribe at gridengine.sunsource.net
> >>>> For additional commands, e-mail:
> >>> users-help at gridengine.sunsource.net
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail:
> users-unsubscribe at gridengine.sunsource.net
> >>> For additional commands, e-mail:
> users-help at gridengine.sunsource.net
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> >> For additional commands, e-mail:
> users-help at gridengine.sunsource.net
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> > For additional commands, e-mail:
> users-help at gridengine.sunsource.net
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list