>Then I'd you run something like: >srun --var=DISPLAY xterm There is no such option when I see the manual page https://slurm.schedmd.com/srun.html Should I write "srun --var=:1" ?
Regards, Mahmood On Fri, Nov 23, 2018 at 1:09 PM Williams, Gareth (IM&T, Clayton) <gareth.willi...@csiro.au> wrote: > In the vncviewer session, what is DISPLAY set to? I guess it will be > something like head.mydomain.com:1 and you can run x applications that > done need much resource. > Then I'd you run something like: > srun --var=DISPLAY xterm > Or sbatch with this script: > #!/bin/bash > xterm > > You should get an xterm in a batch session. > head mydomain.com must be network accessible from the compute nodes. > > Gareth > > Get Outlook for Android <https://aka.ms/ghei36> > > ------------------------------ > *From:* slurm-users <slurm-users-boun...@lists.schedmd.com> on behalf of > Mahmood Naderan <mahmood...@gmail.com> > *Sent:* Friday, November 23, 2018 6:34:42 PM > *To:* Slurm User Community List > *Subject:* Re: [slurm-users] About x11 support > > Hi Gareth, > Thanks for the info. My cluster is not a big one and I have configured in > the following way. > 1- A frontend which has the rocks 7 (based on centos 7) with gnome. Users > login to this node *only* via vncviewer. > 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. > > Now, the question is, why the following error happens when we now that x11 > support had been enabled during the compilation. > > [mahmood@rocks7 ~]$ srun --x11 --nodelist=compute-0-5 -n 1 -c 6 --mem=8G > -A y8 -p RUBY xclock > srun: error: Cannot forward to local display. Can only use X11 forwarding > with network displays. > > > Regards, > Mahmood > > > > > On Fri, Nov 23, 2018 at 3:22 AM Williams, Gareth (IM&T, Clayton) > <gareth.willi...@csiro.au> wrote: > >> 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). >> >> First some preamble: >> * we offer 'login' nodes with limits on what can be run as a >> highest-reliability option for managing batch jobs >> * we offer a set of 'interactive' nodes where there is more flexibility >> for running larger analysis, development and house-keeping tasks. >> * we offer a set of 'visualisation' nodes with gpus and setup for >> hardware accelerated graphics >> * we encourage use of (vnc) virtual desktop sessions, and/or ssh access >> >> In both modes of access we ensure DISPLAY is set in a form that is >> network accessible within the cluster. ie _not_ localhost:NN >> With ssh this is done with the sshd_config X11UseLocalHost=no option. >> >> 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. >> >> No plugin, no compiled in support in slurm. >> >> 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. >> >> Gareth >> >>
