OK, to summarize the scenario:
A normal user connects, gets the first display :50, runs his session. /tmp/.X50-lock and /tmp/.X11-unix/X50 are owned by this user.
The user decides to killall -u username -9. (Don't ask. The actual story was that the logout process didn't complete, and he tried to clean up behind him, having accustomed to use kill -9 all the time.)
This kicks the user's nxagent out of business (the same would happen if it simply crashes), which prevents it from cleaning up the sockets in /tmp.
Another user connects, and also gets assigned the first display (because, for some reason, x2go is convinced it's free again). His x2go processes are not permitted to remove and recreate /tmp/.X50-lock and /tmp/.X11-unix/X50, and the window manager dies immediately. All users besides the initial user are locked out of x2go from now on.
Manual workaround: Remove stale /tmp/.X??-lock and /tmp/.X11-unix/X??. Apply LART to users of kill -9 against nxagent.
Automatic workaround: x2gocleansessions should probably take care of the /tmp file removal. LART will still need to be applied manually.
A "real" fix would move the usual, immediate cleanup step out of the user's control. This could, for example, happen by a daemon running as root, that spawns a nxagent at a user's request, under the user's UID. Once the nxagent dies (from whatever cause), the daemon's SIGCHLD handler does the cleanup. This would also remove the race condition (up to 2s delay before the sockets are cleaned up; connection of new users may be impossible in this time window) introduced by the aforementioned "automatic workaround".
Another, much simpler possibility would be to use randomized/uniqe socket names instead of the fixed /tmp/.X${DISPLAYNUM}-lock / /tmp/.X11-unix/X${DISPLAYNUM} scheme. But I don't know enough about X11 to judge whether this could work.
-- Horst
-- PGP-Key 0xD40E0E7A
Control: clone -1 -2 -3 Control: reopen -2 -3 Control: retitle -2 clean up stable /tmp/.X<disp>-lock files Control: retitle -3 develop X2Go Server session manager Control: severity -2 important Control: severity -3 wishlist
On Fr 03 Okt 2014 21:47:21 CEST, Horst Schirmeier wrote:
Automatic workaround: x2gocleansessions should probably take care of the /tmp file removal. LART will still need to be applied manually.
This is partly already implemented in X2Go Server 4.0.1.17. However, I
missed providing some code that removes the /tmp/.X<disp>-lock file.
For this I have clone a new bug with the title "clean up stable
/tmp/.X<disp>-lock files". I won't be working on X2Go over the
weekend, so from anyone else: patches are welcome.
A "real" fix would move the usual, immediate cleanup step out of the user's control. This could, for example, happen by a daemon running as root, that spawns a nxagent at a user's request, under the user's UID. Once the nxagent dies (from whatever cause), the daemon's SIGCHLD handler does the cleanup. This would also remove the race condition (up to 2s delay before the sockets are cleaned up; connection of new users may be impossible in this time window) introduced by the aforementioned "automatic workaround".
This actually is something we plan for X2Go Server 5.0. There will be
a session management daemon that the clients talk to and the session
management daemon will take care of all the (internal) actions to
provide what clients request. The session management daemon will be
virtually in charge of everything X2Go-related and it will be
event-based and all-knowing.
This feature request will be dealt with as a new bug, titled: "develop
event-based X2Go Server session manager"
Another, much simpler possibility would be to use randomized/uniqe socket names instead of the fixed /tmp/.X${DISPLAYNUM}-lock / /tmp/.X11-unix/X${DISPLAYNUM} scheme. But I don't know enough about X11 to judge whether this could work.
In theory this could be possible, but it would interfere a great deal
with what other X11-related applications / libraries expect. So, this
actually is a no-go IMHO.
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
-
Horst Schirmeier -
Mike Gabriel