Thanks Reuti,
Since qsh relies on a direct connection it will always fails and
should be removed (or forgotten). qrsh xterm fails on our system b/c
only qlogin_command (qconf -sconf) is set to use ssh -X, but qlogin works
fine to open an interaction session, and at that session prompt xterm (or
any other X apps) runs fine via the X tunnel (ie, DISPLAY=localhost:10.0).
I kept wondering why I could not get qsh to work, now I know. Thanks!
Cheers,
Sylvain
--
On Tue, Nov 19, 2019 at 6:52 PM Reuti <re...@staff.uni-marburg.de> wrote:
> Hi,
>
> Am 19.11.2019 um 23:41 schrieb Korzennik, Sylvain:
>
> > While qrsh and qlogin works fine, qsh fails on
> > % qsh
>
> `qsh` uses the old-style invocation only. I.e. it will make a direct
> connection to the submission host, where access has to be granted by `xhost
> +` beforehand (and open ports 6000 upwards on the client, it will increase
> for each new window). Instead of the "localhost:15.0" there should be the
> machine's name noted. Essentially this is judged as being unsafe nowadays.
> The various settings in "sge_conf" are not used.
>
> The built-in version for the communication of the daemons/clients for
> `qrsh` … in SGE has no support for X11 forwarding. Hence the approach by
> `qrsh xterm` should give a suitable result when set up to use "/usr/bin/ssh
> -X -Y".
>
> -- Reuti
>
>
> > Your job 2657108 ("INTERACTIVE") has been submitted
> > waiting for interactive job to be scheduled ...
> > Could not start interactive job (could be some network/firewall related
> problem)
> >
> > from the same prompt/login node, I can
> > % ssh -X compute-64-16 /usr/bin/xterm
> > or
> > % ssh -Y compute-64-16 /usr/bin/xterm
> > but not
> > % ssh compute-64-16 /usr/bin/xterm
> >
> > I do not want to run these 'out-of-band'. I use ssh -Y in the conf
> (qconf -sconf), yet it fails and I can trace this to:
> >
> > 11/19/2019 17:18:19.296800 [10541:143099]: closing all filedescriptors
> from fd 0 to fdmax=1024
> > 11/19/2019 17:18:19.296828 [10541:143099]: further messages are in
> "error" and "trace"
> > 11/19/2019 17:18:19.299121 [10541:143099]: now running with uid=10541,
> euid=10541
> > 11/19/2019 17:18:19.299172 [10541:143099]: execvp(/usr/bin/xterm,
> "/usr/bin/xterm" "-display" "localhost:15.0" "-n" "SGE Interactive
> > Job 2657108 on compute-64-16.cm.cluster in Queue qrsh.iq" "-e"
> "/bin/csh")
> > 11/19/2019 17:18:19.303787 [446:143093]: wait3 returned 143099 (status:
> 256; WIFSIGNALED: 0, WIFEXITED: 1, WEXITSTATUS: 1, WTERMSIG: 0)
> > 11/19/2019 17:18:19.303843 [446:143093]: job exited with exit status 1
> > 11/19/2019 17:18:19.303872 [446:143093]: reaped "job" with pid 143099
> > 11/19/2019 17:18:19.303893 [446:143093]: job exited not due to signal
> > 11/19/2019 17:18:19.303914 [446:143093]: job exited with status 1
> >
> > What magic is needed for the GE to start xterm right? Is this some xauth
> problem?
> >
> > Thanks,
> > Sylvain
> > --
> > _______________________________________________
> > users mailing list
> > users@gridengine.org
> > https://gridengine.org/mailman/listinfo/users
>
>
_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users
