ROOT not opening display/graphics when run from ssh

Newbie
,
1

Hi,

I started having an issue in the graphic display when running ROOT in ssh.
I am using macOS (Big Sur 11.4), everything was working well until I did an update of XQuartz (2.8.1). From that moment, when I try to open a TBrowser or to plot any simple graph/histogram, it just remains stuck after an empty line is shown:

root [0] new TBrowser;

The first thing I tried was to uninstall XQuartz and and re-install the previous version I had (2.7.11) , but this did not solve the problem.

If I run ROOT from my local pc (root version 6.10.08), the graphic is correctly displayed. The issue is only happening when I run it in ssh (tried on two different remote machines, one with root version 6.16.00 while the other with 6.06.04).
What really makes me confused is that this problem appeared to be fixed few days ago, when I connected to a new network and the graphic was successfully displayed. The day after, the problem was there again (same network).

I definitely think that this is not a problem of ROOT itself, but the outcome is that I cannot use the displaying function.
I apologize if this question is not pertinent or appropriate, but maybe some of you experienced the same problem and could help me.

Thanks in advance for any suggestion,

Va

2

Hi @vd128 ,
and welcome to the ROOT forum.
You probably need to enable X11 forwarding through the ssh connection, e.g. using ssh -Y.

Cheers,
Enrico

3

Hi @eguiraud,
thanks for your reply.

Actually I always access with ssh -XY, so it should be something else… also, I have never changed this command and everything was working fine before the X11 update.

Va

4

Uhm ok, when you ssh into the remote machine, what does root -l -q -e 'gROOT->IsBatch()' print?

5

I tried the command, it’s returning false:

$ root -l -q -e 'gROOT->IsBatch()'

(bool) false
6

Ok then ROOT correctly detects that there is an X11 server and is not in batch mode (i.e. ROOT will try to display graphics). Then the problem must be in the X11 forwarding itself.

I’m not sure how to debug this, maybe @couet or @Axel have an idea.

Cheers,
Enrico

7

Once you establish the SSH connection with -Y flag, there are a few ways to test if your X11 forwarding works.

First check if the DISPLAY environment variable is set by running following command in Terminal: echo $DISPLAY. The output should be localhost:##.#

If DISPLAY variable is set proceed with a test described here. Try forwarding a minimal X11 application: xmessage hello. Your window manager should display a primitive dialog.

If any of the above tests fail then something is wrong with the X11 setup or X11 forwarding on the remote machine.

2 Likes
8

Hi @petrstepanov, I tried to do the tests you suggested and I confirm my problem regards X11.
I entered the ssh session with the -v option, and tried to print the $DISPLAY variable. This is what I get:

$ echo $DISPLAY
131.154.193.196:15.0
$ xclock
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 58728
debug1: x11_connect_display: $DISPLAY is launchd
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 131.154.193.196 55788
debug1: channel 1: new [x11]
debug1: confirm x11

and again, it remains stuck. The DISPLAY variable is not localhost:##:# as you were mentioning.
I also tried to run xclock from local machine and I have the same problem, i.e. that it just remains stuck after an empty line without any error message.

I tried again to uninstall XQuartz (this time I also removed its related components) and re-install it, but I still can’t solve the issue.

9

Hi @ vd128, please try setting the DISPLAY variable to localhost:0.0 after you connect to the remote machine. If Bash shell is used in the server then run following command:

export DISPLAY=localhost:0.0

Next try running the xclock command. Hope that helps.

If not then most likely something is wrong with your server configuration. Please refer to this article to ensure the X11 forwarding is setup correctly on the remote machine. Note that you would have to have administrator permissions to modify the server configuration.

10

Thank you @petrstepanov, I followed your suggestions and I managed to solve the problem! Actually, the issues were two: by setting the DISPLAY variable to localhost:0.0 on my local machine, I could restore the local graphic visualization. Doing the same after connecting the remote machine was not working instead; the issue was solved by adding X11Forwarding yes to my /etc/ssh/sshd_config.

I still cannot understand how could be possible that few days ago the problem seemed suddenly solved without doing anything, and then appeared again. But maybe this is not important anymore :wink:

Thanks a lot again!

1 Like