<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Hi Gareth,</div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks for the info. My cluster is not a big one and I have configured in the following way.</div><div class="gmail_default" style="font-family:tahoma,sans-serif">1- A frontend which has the rocks 7 (based on centos 7) with gnome. Users login to this node *only* via vncviewer.</div><div class="gmail_default" style="font-family:tahoma,sans-serif">2- While a user is connected to his gnome desktop, he opens a terminal and may run an interactive GUI job. So, he has to use x11.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Now, the question is, why the following error happens when we now that x11 support had been enabled during the compilation.<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
[mahmood@rocks7 ~]$ srun --x11 --nodelist=compute-0-5 -n 1 -c 6 --mem=8G -A y8 -p RUBY xclock<span class="gmail-im"><br>srun: error: Cannot forward to local display. Can only use X11 forwarding with network displays.</span> <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><font face="tahoma,sans-serif">Regards,<br>Mahmood</font><br><br><br></div></div></div><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 23, 2018 at 3:22 AM Williams, Gareth (IM&T, Clayton) <Gareth.Williams@csiro.au> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">X11 comes up on this list now and then.  I'm often tempted to describe our site's approach and will do so now it case it help others (or someone wants to say why it is a terrible approach).<br>
<br>
First some preamble:<br>
 * we offer 'login' nodes with limits on what can be run as a highest-reliability option for managing batch jobs<br>
 * we offer a set of 'interactive' nodes where there is more flexibility for running larger analysis, development and house-keeping tasks.<br>
 * we offer a set of 'visualisation' nodes with gpus and setup for hardware accelerated graphics<br>
 * we encourage use of (vnc) virtual desktop sessions, and/or ssh access<br>
<br>
In both modes of access we ensure DISPLAY is set in a form that is network accessible within the cluster. ie _not_ localhost:NN<br>
With ssh this is done with the sshd_config X11UseLocalHost=no option.<br>
<br>
With DISPLAY set to a network accessible form and an xauth entry in the home directory, batch processes can access DISPLAY as long as the DISPLAY variable is passed into the job.<br>
<br>
No plugin, no compiled in support in slurm. <br>
<br>
Note that DISPLAY is not in a form immediately accessible outside the cluster (not fqdn of the external interface) and we have various firewalls in place.<br>
<br>
Gareth<br>
<br>
</blockquote></div></div>