Univention Bugzilla – Bug 29105
univention-session-server auf dem TS verbraucht sehr viel CPU Zeit
Last modified: 2013-03-26 09:14:43 CET
-> ps aux|grep univention-session-server test1 1232 54.8 0.0 2404 592 ? Rs 00:07 0:10 univention-session-server strace auf den Prozess gibt tonnenweise "select( ... " aus. -> strace -f -p 1232 ... select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout) ... Sollte der nicht in aller Ruhe auf weiter session Kommandos warten?
Wir sollten prüfen, ob wir Univention Session entfernen können. Ggf. ersetzen durch SSH-interne Features.
univention-ucc-session-ucc-remote wurde nun auf ssh, ohne univention-session, umgestellt. In kurzen Tests auf einem Laptop war die Performance OK. (1) univention-ucc-session-ucc-remote: /usr/share/xsessions/UCC-remote startet nun nur noch ssh auf den TerminalServer unf führt dort das Kommando ucc/session/remote/command (/usr/share/univention-ucc-application-server/KDE) auf. Als SSH Optionen werden hart -X -o StrictHostKeyChecking=no -o BatchMode=yes vorgeben, konfigurierbar ist ConnectTimeout (ucc/session/remote/connection/timeout, default 15) und ServerAliveInterval (ucc/session/remote/session/timeout, default 100). Sollte es ein Problem geben, geht ein xmessage Fenster auf. (2) univention-base-files: Per Patch wurde die UCRV sshd/clientAliveInterval hinzugefügt um ClientAliveInterval in /etc/ssh/sshd_config zu konfigurieren. (3) univention-ucc-application-server: Setzt nun sshd/clientAliveInterval?100 im postinst und bringt /usr/share/univention-ucc-application-server/kill-process-by-display /usr/share/univention-ucc-application-server/KDE mit. /usr/share/univention-ucc-application-server/KDE wird vom Client bei einer Remote Session gestartet. Dieses Script tut folgendes (analog zu TCS) * client/login/script wird ausgeführt * KDE wird gestartet (startkde) * Session wird aufgeräumt (kill-process-by-display) * client/logout/script wird ausgeführt (4) Timeout: Der Timeout wird über SSH geregelt. Auf dem Server wird ClientAliveInterval gesetzt, auf 100. Die Session sollte auf dem Server also nach 300s ohne Erreichbarkeit des Client beendet werden. Auf dem Client wird ServerAliveInterval auf 100 gesetzt, dort sollte es also genauso funktionieren. Hier noch die Beschreibung zur SSH Option (ServerAliveInterval ist analog) ClientAliveInterval Sets a timeout interval in seconds after which if no data has been received from the client, sshd will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client. This option applies to protocol version 2 only. ClientAliveCountMax Sets the number of client alive messages (see above) which may be sent without sshd receiving any messages back from the client. If this threshold is reached while client alive messages are being sent, sshd will disconnect the client, terminating the session. It is important to note that the use of client alive messages is very different from TCPKeepAlive (below). The client alive mes- sages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by TCPKeepAlive is spoofable. The client alive mechanism is valuable when the client or server depend on knowing when a connection has become inactive. The default value is 3. If ClientAliveInterval (above) is set to 15, and ClientAliveCountMax is left at the default, unresponsive ssh clients will be disconnected after approximately 45 seconds
ssh X forwarding ist auf unseren Thin-Clients deutlich zu langsam. Wir sollten das reine X forwarding zumindest noch als konfigurierbare Alternative anbieten.
*** Bug 28349 has been marked as a duplicate of this bug. ***
Zusätzlich zu SSh X-Forwarding kann man nun auch direkt X11 Forwarding verwenden. Dafür muss auf dem Session-Client ucr set lightdm/xserver/allowtcp=yes gesetzt werden. Danach muss einmal der lightdm neu gestartet werden (service lightdm restart). Änderungen: * univention-lightdm: Wenn lightdm/xserver/allowtcp True ist, wird "xserver-allow-tcp=true" in der /etc/lightdm/lightdm.conf gesetzt. * univention-ucc-session-ucc-remote: Das Session Script schaut ebenfalls auf lightdm/xserver/allowtcp. Ist dies True, wird die SSH Option -X NICHT verwendet, statt dessen wird ein entsprechender cookie in "$HOME/.Xauthority" erstellt und auf den Terminal Server kopiert. Da Session Script auf dem Terminal Server wird dann mit dem Parameter "-x11" aufgerufen. * univention-ucc-application-server: Das Session Skript kennt einen neuen Parameter "-x11". Wenn der gesetzt ist, wird die DISPLAY Variable auf $sshClient:0 gesetzt.
(In reply to comment #5) > Zusätzlich zu SSh X-Forwarding kann man nun auch direkt X11 Forwarding > verwenden. Dafür muss auf dem Session-Client > > ucr set lightdm/xserver/allowtcp=yes > > gesetzt werden. Danach muss einmal der lightdm neu gestartet werden (service > lightdm restart). > > Änderungen: > > * univention-lightdm: > Wenn lightdm/xserver/allowtcp True ist, wird "xserver-allow-tcp=true" in der > /etc/lightdm/lightdm.conf gesetzt. > > * univention-ucc-session-ucc-remote: > Das Session Script schaut ebenfalls auf lightdm/xserver/allowtcp. Ist dies > True, wird die SSH Option -X NICHT verwendet, statt dessen wird ein > entsprechender cookie in "$HOME/.Xauthority" erstellt und auf den Terminal > Server kopiert. Da Session Script auf dem Terminal Server wird dann mit dem > Parameter "-x11" aufgerufen. > > * univention-ucc-application-server: > Das Session Skript kennt einen neuen Parameter "-x11". Wenn der gesetzt ist, > wird die DISPLAY Variable auf $sshClient:0 gesetzt. Wenn das von der Performance besser ist sollte das der Default sein. Oder spricht etwas dagegen?
> > Wenn das von der Performance besser ist sollte das der Default sein. Oder > spricht etwas dagegen? Das X "Zeug" geht dann halt unverschlüsselt über die Leitung, aber die Performance an ThinClients ist deutlich besser. Wenn man einen Client mit mehr Rechnerleistung hat, kann man ja wieder auf SSH X Forwarding umstellen. => default ist nun X11 Forwarding
ucc/session/remote/command existiert und wird ausgewertet -> OK Zusätzliche Optionen sind StrictHostKeyChecking=no BatchMode=yes GSSAPIDelegateCredentials=yes -> OK Timeouts konfigurierbar -> OK mit ucr Variable X11 Forwarding aktivierbar -> OK X11 Forwarding ist Standardwert -> OK -> Verified
Einige Messwerte: 1920x1080x24 x11 forwarding: - youtube video standardgröße ansehen: 25MByte/s - Fenster hin- und herschieben: 50MByte/s - "Normales" Arbeiten (schreiben/surfen) < 5MByte/s
UCC 1.0 has been released: http://forum.univention.de/viewtopic.php?f=26&t=2417 http://forum.univention.de/viewtopic.php?f=54&t=2418 If this error occurs again, please use "Clone This Bug".