Univention Bugzilla – Bug 22634
univention-management-console-web-server lässt sich nicht sauber stoppen
Last modified: 2016-08-23 16:27:14 CEST
Der UMC-Web-Server lässt sich derzeit noch nicht sauber beenden über "invoke.rc univention-management-console-web-server stop", dies muss noch überarbeitet werden. Das Server-Skript liegt im SVN unter: dev/branches/ucs-3.0/ucs/management/univention-management-console-frontend Darin müsste die Method UMC_HTTP_Daemon._stop angepasst werden.
Das Problem hatte damit zu tun, dass nur ein KeyboardInterrupt abgefangen wurde. Hinzugefügt wurde jetzt auch die Exception SystemExit, damit bei einem SIGTERM CherryPy richtig beendet werden kann. Hier die Python-Exception-Hierarchie: BaseException +-- SystemExit +-- KeyboardInterrupt +-- GeneratorExit +-- Exception +-- [...] Bei Absturz des UMC-Servers kann es allerdings noch vorkommen, dass Verbindungen offen sind, die nach dem Aufruf von cherrypy.engine.exit() nicht geschlossen werden können. Ein backtrace im gdb deutet darauf hin, dass ein entsprechender Thread in CherryPy nicht mehr korrekt gejoint werden kann, Zeile "worker.join()" in: /usr/share/pyshared/cherrypy/wsgiserver/__init__.py : 1368
Bei mir tritt das manchmal immer noch auf. Das sollten wir nochmal prüfen. Ich vermute, dass es mit dem Beenden des UMC-Server im "ungünstigen" Moment zusammenhängt. Schieben auf MS2
Nach den letzten Änderungen von Andreas, bei denen die Verbindungen zum UMC-Server korrekt geschlossen werden, scheint dieses Problem nicht mehr aufzutreten.
Trat wieder auf bei einem Update der Binärpakete von univention-management-console.
Es kann sein, dass dieses Problem im Zusammenhange mit dem folgenden Verhalten steht. Wird bei einer aktiven Session der Webserver neugestartet und die Webseite neugeladen, so tritt beim einem korrekten Login eine Fehlermeldung auf, die die Fehlernachricht mit in den Header der Antwort schreibt. Dadurch kann der Header nicht mehr geparst und somit der Bei dem Reload wird zunächst umcp/set aufgerufen, um die Locale zu setzen. Dies schlägt fehl, da die Session durch den Reload nicht mehr gültig ist: ==================== <11>Sep 15 14:20:32 python2.6: UMCP_Dispatcher: check_queue: invalid session: sessionid='3b2e3cf7-4a91-40e6-bbd8-1a5dd2fbdd75'<11>Sep 15 14:20:32 python2.6: CPSet (127.0.0.1:46389) response status code: 401<11>Sep 15 14:20:32 python2.6: CPSet (127.0.0.1:46389) response message: NoneHTTP/1.1 401 UnauthorizedDate: Thu, 15 Sep 2011 12:20:32 GMT Content-Length: 89 Content-Type: text/html Server: CherryPy/3.1.2 Connection: close { "status": "401 Unauthorized", "message": "No permission -- see authorization schemes" } ==================== Der Login-Versuch schlägt dann auch fehl mit folgender Antwort: ==================== <11>Sep 15 14:20:35 python2.6: SessionClient: connection to UMC server failed<11>Sep 15 14:20:35 python2.6: SessionClient: _authenticated: success=True status=200 message=OK, operation successfulHTTP/1.1 200 OKDate: Thu, 15 Sep 2011 12:20:35 GMT Content-Length: 0 Content-Type: text/html Server: CherryPy/3.1.2 Set-Cookie: UMCSessionId=551f74a2-c29a-4e72-a848-c3de88cbbc93; Max-Age=600; Path=/; Version=1 Connection: close ====================
(In reply to comment #5) > Es kann sein, dass dieses Problem im Zusammenhange mit dem folgenden Verhalten > steht. Wird bei einer aktiven Session der Webserver neugestartet und die > Webseite neugeladen, so tritt beim einem korrekten Login eine Fehlermeldung > auf, die die Fehlernachricht mit in den Header der Antwort schreibt. Dadurch > kann der Header nicht mehr geparst und somit der Die Fehlerausgabe wird jetzt über CORE.process an Stelle von CORE.error geleitet. Da CORE.error auch in /var/log/syslog geschrieben wurde, schien es da Probleme zu geben. Es bleibt zu überprüfen, ob dadurch auch die Neustartprobleme sich behoben haben.
Es scheint sich um ein Thread-Problem zu handeln, da scheinbar ein Lock beim Beenden nicht mehr freigegeben wird. Es sollte ein Timeout eingebaut werden, der nach ein paar Sekunden den Server via SIGKILL zum Beenden zwingt.
Der Web-Server wird jetzt mit einem KILL getötet, wenn er nach 5 Sekunden nach dem TERM immernoch lebt.
(In reply to comment #8) > Der Web-Server wird jetzt mit einem KILL getötet, wenn er nach 5 Sekunden nach > dem TERM immernoch lebt. OK, der Web-Server wird jetzt nach 5sec zum Beenden gezwungen, das funktioniert.
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"
(In reply to Alexander Kläser from comment #7) > Es scheint sich um ein Thread-Problem zu handeln, da scheinbar ein Lock beim > Beenden nicht mehr freigegeben wird. Es sollte ein Timeout eingebaut werden, > der nach ein paar Sekunden den Server via SIGKILL zum Beenden zwingt. The thread is terminated since svn r63448. Now the UMC-Webserver doesn't take 5 seconds to stop anymore but only 1 second.