Hi Thomas,
On Sa 23 Mär 2013 16:28:28 CET Thomas Hanschke wrote:
Hello everyone;
I have set up a x2go terminal-server on ubuntu 12.04 in our school. There are 25 thinclients (wyse with windows7 embedded) in a classroom. The thinclients start with an openbox-session. So far it works fine, but there is a little problem:
If more than 2 or 3 clients log on at exactly the same time, some of them stop at the black screen before the gray X2Go Logo appears. There is no error message. With a little timeshift of 2 or 3 seconds between the logons, there are no problems.
Can anyone get a little help to solve this?
You experience a race condition where the server tries to allocate a
display port per session and if two users log in very simulataneously,
the second user won't get a valid display.
I am not sure if this can be avoided really reliably. However, instead
of incrementing the X2GO_PORT by 1 in x2gostartagent (in case the
probed port is not usable anymore) we could increment the X2GO_PORT by
some random value (between 1 and 30). Then it could still be that two
clients try to get the same DISPLAY port (in case two random calls
deliver the same value), but the failing logins should reduce by far.
I Cc: our -dev list for further comment.
Mike
--
DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein 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...
Am 23.03.2013 16:54, Mike Gabriel schrieb:
You experience a race condition where the server tries to allocate a display port per session and if two users log in very simulataneously, the second user won't get a valid display.
I am not sure if this can be avoided really reliably. However, instead of incrementing the X2GO_PORT by 1 in x2gostartagent (in case the probed port is not usable anymore) we could increment the X2GO_PORT by some random value (between 1 and 30). Then it could still be that two clients try to get the same DISPLAY port (in case two random calls deliver the same value), but the failing logins should reduce by far.
No, adding randomness is doing it wrong! Normally the db should make sure that no display and the associated port is applied twice. Probably we should check the sqlite code anyway, because sqlite does not support concurrency out of the box. Additionally, if I remember right, before that stuff was rewritten to perl, I wrote an while-loop that looped through the displays until it had a valid display and free ports. Maybe that somehow got lost during the rewrite. Anyway something like that should be added. Maybe: If the agent fails to start check whether ports or display might have been the reason and retry n times silently.
Morty
I'm not familiar with the x2go-project and perl. A while-loop that looped through the displays until it had a valid display and free ports sounds good to me. Can you try to change the x2gostartagent in this way?
Regards Thomas
Hi Thomas,
On Mi 27 Mär 2013 19:04:27 CET Thomas Hanschke wrote:
I'm not familiar with the x2go-project and perl. A while-loop that looped through the displays until it had a valid display and free ports
sounds good to me. Can you try to change the x2gostartagent in this way?Regards Thomas
I can do that some time. So that I do not forget about, could you file
a bug report that expains the issue from scratch including all the
information we have collected so far?
See http://wiki.x2go.org/doku.php/wiki:bugs for a bug reporting howto.
Mike
--
DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein 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...
-
Mike Gabriel -
Moritz Strübe -
Thomas Hanschke