[GE users] SGE 6.1 and qsh failure

Reuti reuti at staff.uni-marburg.de
Fri Jul 20 17:19:43 BST 2007


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

Am 20.07.2007 um 15:15 schrieb Barry McInnes:

> On 7/19/07 5:04 PM, Reuti wrote:
>> Am 19.07.2007 um 22:58 schrieb Barry McInnes:
>>
>>>> You want a safe ssh connection to the node but then use an  
>>>> unsafe direct
>>>> X11 connection back?
>>>>
>>>> AFAIK there is no qsh_command entry. qsh will just start the  
>>>> program you
>>>> set in the global (or node) configuration for "xterm
>>>> /usr/bin/X11/xterm". Often it's working to use just:
>>>>
>>>> qrsh xterm
>>>
>>> qrsh works fine as does qlogin
>>
>> Yes, but is also "qrsh xterm" working?
>
> With your insights we might be getting closer to the problem. I had to
> interrupt the following commands
>
> [mac27:~/.ssh] bmcinnes% qrsh xterm
> ^C^Cerror: error waiting on socket for client to connect: Interrupted
> system call
> error: error reading returncode of remote command
>
> [mac27:~/.ssh] bmcinnes% qrsh /usr/X11R6/bin/xterm
> ^C^Cerror: error waiting on socket for client to connect: Interrupted
> system call
> error: error reading returncode of remote command
> [mac27:~/.ssh] bmcinnes%
>
> I had to force quit, and it returns a socket error. Is it trying to  
> use
> some 6000+ port ?

Yes, this is the usual X11 behavior to use port 6000+. But if you set  
up your ssh definition to supply the -X -Y (or the entries in the  
config files of ssh), this "qrsh xterm" should work. The X11 will  
then tunnel through the already established ssh connection.

rsh_command     /usr/bin/ssh -X -Y

and

qrsh xterm

should work.

> I had to reset the port in the ql.sh to 22 to get qlogin qnd qrsh to
> operate, from what SGE wanted to use which hung those commands  
> before I
> forced port 22.
> The Macs only have login and ARD allowed on the firewall, so maybe  
> that
> is stopping qsh, qlthough qrsh without a command works ?

Exactly, but a qrsh with a command besides /usr/X11R6/bin/xterm  
should also work, e.g.

qrsh ls

>>>>
>>>> if you setup your ssh-wrapper in SGE to have the option -Y or  
>>>> put this
>>>> option in the global /etc/ssh/ssh_config or private ~/.ssh/ 
>>>> config like:
>>>>
>>>> Host *
>>>>     ForwardAgent yes
>>>>     ForwardX11 yes
>>>>     ForwardX11Trusted yes
>>>>     Compression yes
>>>>     NoHostAuthenticationForLocalhost yes
>>>>     ServerAliveInterval 900
>>>
>>> I tried the above settings in private config file, with no gain.
>>> All macs have been setup to use passwordless, so this works
>>> [mac27:~/.ssh] bmcinnes% ssh mac05
>>> [mac05:~] bmcinnes%
>>>
>>>> (and maybe it's of interest: optionally have on the Mac the
>>>> http://www.phil.uu.nl/~xges/blog/ssh running with the same  
>>>> options you
>>>> could even use a passphrase in your ssh-keys without the need to  
>>>> enter
>>>> it all the time. A good explanation for the use of the ssh-agent  
>>>> I found
>>>> here: http://www.unixwiz.net/techtips/ssh-agent-forwarding.html).
>>>
>>> If there is no obvious solution, I will live without qsh, but  
>>> here is
>>> the same tests as in the first email after using the above config.
>>>
>>> mac27:~/.ssh] bmcinnes% qsh -display :0.0 -e -v
>>> error: local DISPLAY variable ":0.0" delivered with interactive job
>>> [mac27:~/.ssh] bmcinnes% qsh -display mac27:0.0 -e -v
>>> Your job 34871 ("INTERACTIVE") has been submitted
>>> waiting for interactive job to be scheduled ...
>>> Could not start interactive job.
>>> [mac27:~/.ssh] bmcinnes% qsh -display mac27.cdc.noaa.gov:0.0 -e -v
>>> Your job 34872 ("INTERACTIVE") has been submitted
>>> waiting for interactive job to be scheduled ...
>>> Could not start interactive job.
>>
>> What are these "-e -v" options - to qsh an error output with name -v?
>>
>> qsh -display mac27:0.0
>>
>> we should get working.
>>
>> qsh -display mac27:0.0 -w v
>>
>> shows suitable queues?
>
> They were just options I entered, I figured -v would work. Here are  
> your
> options. It takes about 5 secs waiting for scheduler, then says Could
> not start.
>
> [mac27:~/.ssh] bmcinnes% qsh -display mac27:0.0 -w v
> verification: found suitable queue(s)

Okay.

> [mac27:~/.ssh] bmcinnes% qsh -display mac27:0.0

This will not work directly. qsh will just (and only) start the xterm  
on the remote node in the cluster (as defined with "qconf -mconf"),  
and try to connect to your local machine with port 6000+ - which  
can't be used in your environment of course.

-- Reuti


> Your job 34878 ("INTERACTIVE") has been submitted
> waiting for interactive job to be scheduled ...
> Could not start interactive job.
> [mac27:~/.ssh] bmcinnes%
>
>
>>
>> -- Reuti
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>> For additional commands, e-mail: users-help at gridengine.sunsource.net
>>
>
> -- 
> ---
> Barry McInnes
> 325 Broadway
> Boulder CO 80304
> (303)4976231
> barry.j.mcinnes at noaa.gov
> ---
>
> ---------------------------------------------------------------------
> 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