[GE users] Cloned upgrade and port numbers

petrik lubomir.petrik at sun.com
Thu Sep 3 16:00:53 BST 2009


Hi,
simply backup your settings ($SGE_ROOT, etc.), so that you can always do 
to the state before the upgrade. See my inline comments.

Regards,
   Lubos.

heywood wrote:
> Reuti, thanks for the info. Replies inline below...
>
> On 9/2/09 5:06 PM, "reuti" <reuti at staff.uni-marburg.de> wrote:
>
>   
>> Hi,
>>
>> Am 02.09.2009 um 21:13 schrieb heywood:
>>
>>     
>>> I'm trying a cloned upgrade of SGE to 6.2u3. Our current production
>>> SGE uses
>>> /etc/services to define the qmaster and sge_execd ports since
>>> qmaster and
>>> execd start on boot (they will not start without sge_qmaster and
>>> sge_execd
>>> in /etc/services since settings.sh is not sourced on boot).
>>>       
>> when you setup a cluster with hardcoded port numbers, they will be
>> recorded also in the scripts sgeexecd and sgemaster.
>>
>> There you can define anything you like and don't have to source
>> settings.sh; just put the export command after the comment regarding
>> the LSB compliance.
>>     
>
> You are suggesting I manually edit the sgeexecd and sgemaster scripts to
> define the ports with exports, and then delete their entries in
> /etc/services?
>   
No need for that simply do what you are doing and don't abort. Choose 
the use env variables, not the /etc/services and enter a new unused 
ports. The upgrade will generate new startup/RC scripts with the new 
values for the new cloned cluster.
> Note that the way things are now, sgeexecd and sgemaster do not start unless
> they have port number entries in /etc/services (but no error messages are
> given either if I try to start them without their entries in /etc/services).
>
>   
>>     
>>> It seems to me that I cannot do the cloned upgrade since I can't
>>> define
>>> different port numbers in /etc/services for the new version for the
>>> same
>>> service names sge_qmaster and sge_execd.
>>>       
>> It's possible to have more than one sgemaster/-execd running on the
>> same machine from different versions. You will just need to use
>> different port pairs for each instance. For your commands qstat,
>> qconf, ... you need to change the to be used ports along with the
>> cell name to access each of them.
>>
>>
>>     
>>> Right? How do other people deal with this? I aborted the upgrade
>>> procedure
>>> since it looked like it was about to changes the sge_execd port
>>> number in
>>> /etc/services, which would screw up the current production SGE if
>>> it indeed
>>> did that....
>>>       
>> I never saw SGE touching the file /etc/services.
>>     
>
> Well the cloned upgrade procedure tells me I have the ports "curently set
> BOTH as service and by the shell environment" and asks how I want to change
> them. I say "shell environment" (the default). Then it says the following
> which is confusing...
>
> Grid Engine TCP/IP communication service
> ----------------------------------------
>
> Using the environment variable
>
>    $SGE_EXECD_PORT=6455
>
> as port for communication.
>
> This overrides the preset TCP/IP service >sge_execd<.
>
> Do you want to change the port number? (y/n) [n] >> y
>   
This screen is saying that the port number is set by both SGE_EXECD_PORT 
env value and in /etc/services. You choose the env, so this screen 
offers you to change it.
>
>
> Grid Engine TCP/IP service >sge_execd<
>
> --------------------------------------
>
> Please enter an unused port number >>
>   
Just enter a SGE_EXECD_PORT number for the new cluster.
>
>
> ...at which point I aborted.
>
> Todd
>
>
>
>
>
>   
>> -- Reuti
>>
>>
>>     
>>> Grid Engine TCP/IP service >sge_execd<
>>>
>>> --------------------------------------
>>>
>>> Please enter an unused port number >>
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Todd
>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?
>>> dsForumId=38&dsMessageId=215504
>>>
>>> To unsubscribe from this discussion, e-mail: [users-
>>> unsubscribe at gridengine.sunsource.net].
>>>       
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=215
>> 521
>>
>> To unsubscribe from this discussion, e-mail:
>> [users-unsubscribe at gridengine.sunsource.net].
>>     
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=215633
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=215635

To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].



More information about the gridengine-users mailing list