Hello everybody,
I've running X2Go (v4.0.1.20) on CentoOS6 and it works quite well.
Last week I was out of office and I kept a session running on the "server". When I came back, I was not able to connect to session again. The client stucks after starting the connection, after >1/2h I killed the client. When I try to connect afterwards, I have to suspend the session 1st, then I can connect, but the client stucks again.
On the server /var/log/messages is blown up by lot of this messages: Nov 17 09:18:32 lmesim138 /usr/bin/x2gosuspend-session: session with ID lmegast5-50-1507636342_stDGNOME_dp32 has been suspended successfully Nov 17 09:18:32 lmesim138 /usr/bin/x2gosuspend-session: session with ID lmegast5-50-1507636342_stDGNOME_dp32 has been suspended successfully Nov 17 09:18:42 lmesim138 /usr/bin/x2gosuspend-session: session with ID lmegast5-50-1507636342_stDGNOME_dp32 has been suspended successfully
This message is added even if no client is trying to connect or disconnect.
Taking a look on the open files (lsof) shows that the session log file in /tmp has been deleted meanwhile: /tmp/.x2go-lmegast5/C-lmegast5-50-1507636342_stDGNOME_dp32/session.log (deleted) (background: "old" files in /tmp are deleted automatically after 3 weeks of beeing not used/touched)
I assume thats the reason why I cannot connect to the session again.
Do you have an idea how I might make the session working again or overcome the problem in general? (I sometimes have simulations running for a longer time and the result/evaluation will be done and shown within this session)
Best regards, Markus
Taking a look on the open files (lsof) shows that the session log file in /tmp has been deleted meanwhile: /tmp/.x2go-lmegast5/C-lmegast5-50-1507636342_stDGNOME_dp32/session.log (deleted) (background: "old" files in /tmp are deleted automatically after 3 weeks of beeing not used/touched)
I assume thats the reason why I cannot connect to the session again.
Do you have an idea how I might make the session working again or overcome the problem in general? (I sometimes have simulations running for a longer time and the result/evaluation will be done and shown within this session)
Please disable this automatic /tmp cleanup to avoid having such problems in the future. Or make it smarter - e.g., by only deleting old files that are bigger than say 5 MB.
There is no trivial way to connect back to the session with X2Go Client after the session metadata has been deleted.
One thing you could try is to start a new "identical" session, then take a copy of this session data, then terminate the session again and put the copy of the session data in place of the old deleted session data. Doing so, make sure to replace the differing parts, like DISPLAY number (will likely be 51 instead of 50) and UNIX timestamp, but maybe others as well. This holds for both the directory name (of course), but also the contents of the files in there. And it's quite a lot of data to change, for instance you'll also need to fetch the TCP port to connect to and the authorization cookie.
Luckily, this information should still be available in the database. x2golistsessions executed as the user in question on the server side should give you the needed data.
A more manual way, bypassing X2Go session management, would be to connect to the x2goagent process directly.
ssh -X (or ssh -Y) to the machine, then spawn another shell on that machine, then execute x2golistsessions.
After you've got the needed information, connect directly via nxproxy -S nx/nx,cookie=$SESSION_COOKIE,connect=localhost,port=$TCP_PORT:50
On the other terminal issue kill -HUP $AGENT_PID.
$AGENT_PID is the integer in the first column of the output. $SESSION_COOKIE is the 32 character string in the 7th column. $TCP_PORT is the integer in the 9th column.
After that, just wait. The proxy should be able to connect.
Note that this is using SSH X11 forwarding, so it will be very slow depending on both links.
Mihai