hi Mihai and other x2go users,
I am wondering if you have any further comments or suggestions, I am still unable to connect to more than half of my servers. All failed in the same messages:
*On the client side:*
|Connection failed.||Failed to start X2Go Agent session with ID fangq-...._stDXFCE_dp24. X2Go Agent terminated unexpectedly. Aborting session startup. |
*on the server side:*
|Info: Agent running with pid '4112'.||||Session: Starting session at 'Tue Apr 10 01:15:16 2018'.||||Error: Aborting session with 'Unable to open display 'nx/nx,options=/tmp/.x2go-fangq/C-fangq-...._stDXFCE_dp24/options:51''.||||Session: Aborting session at 'Tue Apr 10 01:15:16 2018'.||||Session: Session aborted at 'Tue Apr 10 01:15:16 2018'.|
all updated with the latest version of Ubuntu 14.04
Qianqian
On 03/26/2018 10:46 PM, Qianqian Fang wrote:
On 03/26/2018 10:44 PM, Mihai Moldovan wrote:
Looks good, all old packages are in rc state (i.e., uninstalled, but not purged). Sorry, that should have been ls -ldh /usr/lib/*86*/nx/X11/*
I'm interested in the files in there.
here you go | ||*fangq@zodiac:~$ ls -ldh /usr/lib/*86*/nx/X11/**|| ||lrwxrwxrwx 1 root root 20 Mar 17 08:41 /usr/lib/x86_64-linux-gnu/nx/X11/libX11.so.6 -> ../../libNX_X11.so.6|| ||lrwxrwxrwx 1 root root 24 Mar 17 08:41 /usr/lib/x86_64-linux-gnu/nx/X11/libX11.so.6.3.0 -> ../../libNX_X11.so.6.3.0|
Like the other user on the mailing list wrote, purging sessions can be done using rm -vf /var/lib/x2go/x2go_sessions; x2godbadmin --createdb (both as root), but if there are no sessions currently that won't do anything useful.
I see. are there other logs that I can find/provide to narrow down the issue?
thank you again for your help.
Qianqian
Mihai
I changed the title of this thread. I believe this error message is the cause of the problem, but I don't know how to fix.
Right now, among the dozen Ubuntu 14.04 servers I run, half of them x2go works, and other half do not work.
all machines have applied the latest updates (x2go 4.1.0-1517 for the server components, 4.1.1.1-1719 for the client, and libnx-x11-6: 2:3.5.99.16-0)
I compared the package versions, I can't see any difference between the servers that x2go works vs those failed - all x2go/nx components have identical versions.
when connecting to the machine have problems, the server side log gives "|Unable to open display 'nx/nx|", full log see below.
this issue only happens in March after some x2go package updates.
please help!
Qianqian
On 04/10/2018 01:19 AM, Qianqian Fang wrote:
hi Mihai and other x2go users,
I am wondering if you have any further comments or suggestions, I am still unable to connect to more than half of my servers. All failed in the same messages:
*On the client side:*
|Connection failed.||Failed to start X2Go Agent session with ID fangq-...._stDXFCE_dp24. X2Go Agent terminated unexpectedly. Aborting session startup. |
*on the server side:*
|Info: Agent running with pid '4112'.||||Session: Starting session at 'Tue Apr 10 01:15:16 2018'.||||Error: Aborting session with 'Unable to open display 'nx/nx,options=/tmp/.x2go-fangq/C-fangq-...._stDXFCE_dp24/options:51''.||||Session: Aborting session at 'Tue Apr 10 01:15:16 2018'.||||Session: Session aborted at 'Tue Apr 10 01:15:16 2018'.|
all updated with the latest version of Ubuntu 14.04
Qianqian
On 03/26/2018 10:46 PM, Qianqian Fang wrote:
On 03/26/2018 10:44 PM, Mihai Moldovan wrote:
Looks good, all old packages are in rc state (i.e., uninstalled, but not purged). Sorry, that should have been ls -ldh /usr/lib/*86*/nx/X11/*
I'm interested in the files in there.
here you go | ||*fangq@zodiac:~$ ls -ldh /usr/lib/*86*/nx/X11/**|| ||lrwxrwxrwx 1 root root 20 Mar 17 08:41 /usr/lib/x86_64-linux-gnu/nx/X11/libX11.so.6 -> ../../libNX_X11.so.6|| ||lrwxrwxrwx 1 root root 24 Mar 17 08:41 /usr/lib/x86_64-linux-gnu/nx/X11/libX11.so.6.3.0 -> ../../libNX_X11.so.6.3.0|
Like the other user on the mailing list wrote, purging sessions can be done using rm -vf /var/lib/x2go/x2go_sessions; x2godbadmin --createdb (both as root), but if there are no sessions currently that won't do anything useful.
I see. are there other logs that I can find/provide to narrow down the issue?
thank you again for your help.
Qianqian
Mihai
On Sat, Apr 14, 2018 at 8:06 PM, Qianqian Fang <fangqq@gmail.com> wrote:
I changed the title of this thread. I believe this error message is the cause of the problem, but I don't know how to fix.
Right now, among the dozen Ubuntu 14.04 servers I run, half of them x2go works, and other half do not work.
all machines have applied the latest updates (x2go 4.1.0-1517 for the server components, 4.1.1.1-1719 for the client, and libnx-x11-6: 2:3.5.99.16-0)
I compared the package versions, I can't see any difference between the servers that x2go works vs those failed - all x2go/nx components have identical versions.
when connecting to the machine have problems, the server side log gives "Unable to open display 'nx/nx", full log see below.
this issue only happens in March after some x2go package updates.
please help!
Info: Agent running with pid '4112'. Session: Starting session at 'Tue Apr 10 01:15:16 2018'. Error: Aborting session with 'Unable to open display 'nx/nx,options=/tmp/.x2go-fangq/C-fangq-...._stDXFCE_dp24/options:51''. Session: Aborting session at 'Tue Apr 10 01:15:16 2018'. Session: Session aborted at 'Tue Apr 10 01:15:16 2018'.
I see you are using a rather unusual date format. So I am wondering if the might be related to the locale you are using. Please post the output of the "locale" command.
Uli
On 04/14/2018 03:35 PM, Ulrich Sibiller wrote:
Info: Agent running with pid '4112'. Session: Starting session at 'Tue Apr 10 01:15:16 2018'. Error: Aborting session with 'Unable to open display 'nx/nx,options=/tmp/.x2go-fangq/C-fangq-...._stDXFCE_dp24/options:51''. Session: Aborting session at 'Tue Apr 10 01:15:16 2018'. Session: Session aborted at 'Tue Apr 10 01:15:16 2018'. I see you are using a rather unusual date format. So I am wondering if the might be related to the locale you are using. Please post the output of the "locale" command.
hi Uli
the locales on both the "working" and "nonworking" machines are en_US.UTF-8, the full output is
*|fangq@neza:~$ locale|*| ||LANG=en_US.UTF-8|| ||LANGUAGE=|| ||LC_CTYPE="en_US.UTF-8"|| ||LC_NUMERIC=en_US.UTF-8|| ||LC_TIME=en_US.UTF-8|| ||LC_COLLATE="en_US.UTF-8"|| ||LC_MONETARY=en_US.UTF-8|| ||LC_MESSAGES="en_US.UTF-8"|| ||LC_PAPER=en_US.UTF-8|| ||LC_NAME=en_US.UTF-8|| ||LC_ADDRESS=en_US.UTF-8|| ||LC_TELEPHONE=en_US.UTF-8|| ||LC_MEASUREMENT=en_US.UTF-8|| ||LC_IDENTIFICATION=en_US.UTF-8|| ||LC_ALL=
| I also dumped the environment variables for the working (env > good.txt) and the non-working (env > bad.txt) and the difference is listed below. the |/space/hoyi/1/users/shared/mesa-10.1.3 |in LD_LIBRARY_PATH enables to run opengl programs in the remote session, I added it to the non-working machine LD_LIBRARY_PATH, but still get the same error message.|
|||*|fangq@taote:~$ diff good.txt bad.txt |*| ||2c2|| ||< XDG_SESSION_ID=4|| ||---|| ||> XDG_SESSION_ID=11|| ||8c8|| ||< XDG_SESSION_COOKIE=1330194a2eadd749c3beabd157520f0a-1523747416.936381-1031780882|| ||---|| ||> XDG_SESSION_COOKIE=1330194a2eadd749c3beabd157520f0a-1523747426.95076-1702226505|| ||10c10|| ||< SSH_CLIENT=173.xx.xx.xx 38437 22|| ||---|| ||> SSH_CLIENT=129.xx.xx.xx 38556 22|| ||13c13|| ||< SSH_TTY=/dev/pts/26|| ||---|| ||> SSH_TTY=/dev/pts/27|| ||15c15|| ||< LD_LIBRARY_PATH=/usr/local/cuda/lib64:/usr/lib:/pub/lib:/pub/cuda-7.5/lib64:/space/hoyi/1/users/shared/mesa-10.1.3:/usr/lib/x86_64-linux-gnu/mesa:/usr/lib/nvidia-375:/usr/lib/nvidia-387:/usr/lib/nvidia-384|| ||---|| ||> LD_LIBRARY_PATH=/usr/local/cuda/lib64:/usr/lib:/pub/lib:/pub/cuda-7.5/lib64:/usr/lib/nvidia-375:/usr/lib/nvidia-387:/usr/lib/nvidia-384:/usr/lib/x86_64-linux-gnu|| ||31c31|| ||< SSH_CONNECTION=|||173.xx.xx.xx| 38437 129.xx.xx.xx 22|| ||---|| ||> SSH_CONNECTION=|||129.xx.xx.xx| 38556 129.|||xx.xx.xx| 22|
Qianqian
Uli
- On 04/15/2018 01:39 AM, Qianqian Fang wrote:
||< LD_LIBRARY_PATH=/usr/local/cuda/lib64:/usr/lib:/pub/lib:/pub/cuda-7.5/lib64:/space/hoyi/1/users/shared/mesa-10.1.3:/usr/lib/x86_64-linux-gnu/mesa:/usr/lib/nvidia-375:/usr/lib/nvidia-387:/usr/lib/nvidia-384|| ||---|| ||> LD_LIBRARY_PATH=/usr/local/cuda/lib64:/usr/lib:/pub/lib:/pub/cuda-7.5/lib64:/usr/lib/nvidia-375:/usr/lib/nvidia-387:/usr/lib/nvidia-384:/usr/lib/x86_64-linux-gnu||
I haven't had an idea how to help further, thus kept quiet.
This is interesting though - and could explain your problems.
First of all, you shouldn't set LD_LIBRARY_PATH at all. The new X2Go Server versions don't do it and you shouldn't either. /usr/lib/x86_64-linux-gnu in there should even be fully redundant and messes with the default linking order. Not just that, but it means that our DT_RUNTIME trick in nxagent, which is supposed to override libX11 linking against a compatibility symlink (libX11 -> libNX11) installed in a specific directory, is not working - hence loading the wrong libX11 library and thus leading to nxagent failing to open its internal display.
Be careful when you mess with stuff with that.
Mihai
On 04/14/2018 09:30 PM, Mihai Moldovan wrote:
I haven't had an idea how to help further, thus kept quiet. This is interesting though - and could explain your problems.
First of all, you shouldn't set LD_LIBRARY_PATH at all. The new X2Go Server versions don't do it and you shouldn't either. /usr/lib/x86_64-linux-gnu in there should even be fully redundant and messes with the default linking order. Not just that, but it means that our DT_RUNTIME trick in nxagent, which is supposed to override libX11 linking against a compatibility symlink (libX11 -> libNX11) installed in a specific directory, is not working - hence loading the wrong libX11 library and thus leading to nxagent failing to open its internal display.
hi Mihai
thank you so much! the /usr/lib/x86_64-linux-gnu in the LD_LIBRARY_PATH was indeed the culprit! after removing it, I am now able to log in all my servers!
I checked my file modification history for .bashrc, I added this path for a subset of my machines on March 11. It was also the window when I applied the package updates throughout my cluster, so I mistook the issue to the new packages. my bad!
once again, thank you for the insightful suggestions, and I am so happy x2go works again!
Qianqian
Be careful when you mess with stuff with that.
Mihai
- On 04/15/2018 04:59 AM, Qianqian Fang wrote:
thank you so much! the /usr/lib/x86_64-linux-gnu in the LD_LIBRARY_PATH was indeed the culprit! after removing it, I am now able to log in all my servers!
I checked my file modification history for .bashrc, I added this path for a subset of my machines on March 11. It was also the window when I applied the package updates throughout my cluster, so I mistook the issue to the new packages. my bad!
Actually, that makes sense - we've only started using DT_RUNPATH with nx-libs 3.5.99.14, starting with March when we also switched to using this new version. Before that, we inserted the correct link through LD_LIBRARY_PATH as well, but I cannot remember if it was prepended or appended. If it was prepended, your modification would have worked, otherwise not.
So it's been a combination of both things.
Try to keep LD_LIBRARY_PATH trimmed down. I understand that you may need it for the nVidia binary driver and CUDA to work, but this might become problematic in the future. Currently, we're statically linking in a copy of MESA into nxagent and don't use the system libGL version that is normally provided by MESA, but this might change in the future. If the system libGL references the nVidia binary version, you'll run into problems again. It's not something that will hit you right away, but likely at an unspecific point in the future. Just as a heads-up.
Mihai
-
Mihai Moldovan -
Qianqian Fang -
Ulrich Sibiller