Bug 22634 - univention-management-console-web-server lässt sich nicht sauber stoppen
univention-management-console-web-server lässt sich nicht sauber stoppen
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UMC (Generic)
UCS 3.0
Other Linux
: P5 normal (vote)
: UCS 3.0 - RC
Assigned To: Andreas Büsching
Alexander Kläser
: interim-1
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-30 14:44 CEST by Alexander Kläser
Modified: 2016-08-23 16:27 CEST (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kläser univentionstaff 2011-05-30 14:44:52 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.
Comment 1 Alexander Kläser univentionstaff 2011-06-09 15:32:21 CEST
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
Comment 2 Andreas Büsching univentionstaff 2011-08-09 09:06:05 CEST
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
Comment 3 Alexander Kläser univentionstaff 2011-09-12 15:37:21 CEST
Nach den letzten Änderungen von Andreas, bei denen die Verbindungen zum UMC-Server korrekt geschlossen werden, scheint dieses Problem nicht mehr aufzutreten.
Comment 4 Alexander Kläser univentionstaff 2011-09-13 17:44:51 CEST
Trat wieder auf bei einem Update der Binärpakete von univention-management-console.
Comment 5 Alexander Kläser univentionstaff 2011-09-15 14:32:27 CEST
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

====================
Comment 6 Alexander Kläser univentionstaff 2011-09-15 14:47:28 CEST
(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.
Comment 7 Alexander Kläser univentionstaff 2011-09-16 15:37:34 CEST
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.
Comment 8 Andreas Büsching univentionstaff 2011-10-04 17:51:45 CEST
Der Web-Server wird jetzt mit einem KILL getötet, wenn er nach 5 Sekunden nach dem TERM immernoch lebt.
Comment 9 Alexander Kläser univentionstaff 2011-12-02 10:18:27 CET
(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.
Comment 10 Sönke Schwardt-Krummrich univentionstaff 2011-12-13 15:51:24 CET
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"
Comment 11 Florian Best univentionstaff 2016-08-23 16:27:14 CEST
(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.