- On 03/28/2018 02:58 PM, Ivan Gomez wrote:
libNX_X11-3.5.0.32-3.el7.x86_64 libNX_Xcomposite-3.5.0.32-3.el7.x86_64 libNX_Xdamage-3.5.0.32-3.el7.x86_64 libNX_Xdmcp-3.5.0.32-3.el7.x86_64 libNX_Xext-3.5.0.32-3.el7.x86_64 libNX_Xfixes-3.5.0.32-3.el7.x86_64 libNX_Xinerama-3.5.0.32-3.el7.x86_64 libNX_Xpm-3.5.0.32-3.el7.x86_64 libNX_Xrandr-3.5.0.32-3.el7.x86_64 libNX_Xrender-3.5.0.32-3.el7.x86_64 libNX_Xtst-3.5.0.32-3.el7.x86_64 nxagent-3.5.0.32-3.el7.x86_64 nx-libs-3.5.0.32-3.el7.x86_64 x2goagent-3.5.0.32-3.el7.x86_64 x2goserver-4.0.1.20-1.el7.x86_64
That's the old, more or less unsupported version and additionally provided by EPEL, not by our repositories.
One new update on this issue: Updated x2gosever on one of the servers that was showing the issue to x2goserver-4.0.1.22-2.el7.x86_64. After the update, access through that server started working again. Any guidance to understand the root cause would still be greatly appreciated.
I'm afraid I can't offer a lot of help here.
You could look into ~/.x2go/C-<session-id>/session.log to see what the server-side process logged out.
At some point it must have failed to run correctly, otherwise the client-side nxproxy would have been able to connect successfully.
Debugging such issues is always difficult.
Mihai