Univention Bugzilla – Bug 27202
no room selected
Last modified: 2013-02-15 17:50:58 CET
Created attachment 4381 [details] management-console-module-computerroom.log Bei laufender Sitzung kommt nach einiger Zeit der Fehler "No room selected". Im Anhang das logfile mit debuglevel 4.
21.05.12 10:25:25.722 MAIN ( WARN ) : Socket died (module=computerroom) 21.05.12 10:25:25.722 MAIN ( WARN ) : Module process computerroom died (pid: 24304, exit status: -1, signal: -1) 21.05.12 10:25:25.722 MAIN ( INFO ) : Checking for kill timer () 21.05.12 10:25:25.722 MAIN ( WARN ) : Cleaning up requests 21.05.12 10:25:25.722 MAIN ( INFO ) : No pending requests found 21.05.12 10:25:25.722 MAIN ( WARN ) : Remove inactivity timer 21.05.12 10:25:25.723 MAIN ( PROCESS ) : ModuleProcess: child died 21.05.12 10:25:25.723 MAIN ( WARN ) : Module process computerroom died (pid: 24304, exit status: -1, signal: 11) 21.05.12 10:25:25.723 MAIN ( INFO ) : Checking for kill timer () 21.05.12 10:25:26.294 PARSER ( INFO ) : UMCP REQUEST 133758872624485-1037 parsed successfully 21.05.12 10:25:26.294 MAIN ( INFO ) : Incoming request of type COMMAND 21.05.12 10:25:26.294 RESOURCES ( INFO ) : Searching for module providing command computerroom/update 21.05.12 10:25:26.294 RESOURCES ( INFO ) : Found module computerroom
Created attachment 4382 [details] management-console-server.log hier die gesamte server.log, am besten durchsuchen nach 10:25, das ist der gesuchte Zeitpunkt
Created attachment 4384 [details] gdb backtrace
Der Prozess stirbt in einem malloc während das System für eine Anfrage von 65536 Bytes definitiv noch genug Speicher hat. Das ist so noch nicht aussagekräftig. Ich versuch es auf einem anderen System noch einmal zu reproduzieren.
*** Bug 28659 has been marked as a duplicate of this bug. ***
Bug #27534 und #27344 könnten eventuell damit zusammenhängen (duplikate?!).
Problem ist nicht das malloc sondern das "str=0x0". Von der Zeichenkette str soll die Länge ermittelt werden. Eine klassisches Null-Pointer-Problem, was auch die Beendigung mit Signal 11 erklärt. #2 0x00007f6acc1b0a30 in malloc () from /lib/libc.so.6 #3 0x000000000045e262 in PyString_FromStringAndSize (str=0x0, size=65536) at ../Objects/stringobject.c:83
(In reply to comment #7) > Problem ist nicht das malloc sondern das "str=0x0". Von der Zeichenkette str > soll die Länge ermittelt werden. Eine klassisches Null-Pointer-Problem, was > auch die Beendigung mit Signal 11 erklärt. > > #2 0x00007f6acc1b0a30 in malloc () from /lib/libc.so.6 > #3 0x000000000045e262 in PyString_FromStringAndSize (str=0x0, size=65536) at > ../Objects/stringobject.c:83 Hm... > #4 0x00000000004fb80f in sock_recv (s=0x33d1510, args=<value optimized out>) at ../Modules/socketmodule.c:2394 > #5 0x00000000004a7ba5 in call_function (f= > Frame 0x3424d10, for file /usr/lib/pymodules/python2.6/univention/management/console/protocol/modserver.py, line 117 In Zeile 117 in modserver.py steht "sys.exit( 0 )" (Funktion _timed_out).
Created attachment 4697 [details] JS-seitiger Patch für Workaround im Computerraum-Modul "No room selected" wird ausgegeben, da der Python-Modul-Prozess unerwartet beendet wird. In diesem Fall schlägt eine Aktualisierung der Raumdaten fehl (über das Kommando umcp/command/computerroom/update, dieses wird alle 2 Sekunden aufgerufen), da ein neuer Python-Prozess gestartet wird und dieser noch nicht mit den nötigen Informationen (für welchen Raum werden Informationen abgerufen) initialisiert wurde (über das Kommando umcp/command/computerroom/acquire). Der beigefügte Patch ruft nun JavaScript-seitig im Falle eines Fehlers das Initialisierungskommando (computerroom/acquire) erneut auf. Dies wird 5 Mal versucht. Gelingt dies danach immer noch nicht, wird eine entsprechende Meldung als Alert ausgegeben und der initiale Raumauswahldialog gezeigt. In meinen Versuchen funktionierte das sehr gut. Nachdem ich den Modulprozess über kill beendet hatte, wurde die Verbindung wieder erfolgreich aufgenommen. FYI, schlägt ein update-Kommando fehl, wird auf der JavaScript-Fehlerkonsole die folgende Meldung angezeigt: WARN: the command 'computerroom/update' failed
Ich habe den Fehler auf die Schnelle nicht nachstellen können (außer mit einem kill $pid). Wenn iTalc (bzw. die python-Bindings) hin und wieder das Modul zum Absturz bringen ist das übel. Korrekt müsste man also iTalc patchen. Der JS-Workaround funktioniert wahrscheinlich, löst aber nur ein Symptom eines größeren Problems: Das Modul muss jedes Mal mit room/aquire initialisiert werden. Das ist durchaus problematisch, denn der Raum wird im Prinzip "global" dem Modul mitgeteilt und alle anfragen beziehen sich fortan auf Computer aus diesem Raum. Das ist so, als würde man im UDM-Modul den Flavor nicht jedes Mal mitsenden, sondern einmal beim Öffnen eines Moduls speichern. Sobald man zwei Module "Computerraum" aufmacht und dann auch noch einen anderen Raum im zweiten Modul auswählt, kommt es zu jeder Menge Fehler wegen "Unknown Computer" im ersten. Man müsste also eigentlich jedes Mal die DN des Raums mitsenden. Und das Modul müsste dann jedes Mal neu in diesem Raum die Computer suchen. Clevererweise sollte man trotzdem versuchen, das irgendwie zu cachen. Insgesamt würde ich den Fehler aber lieber auf Python-Seite beheben. Da umfangreicher und fehleranfällig, könnte man ihn auch schieben.
(In reply to comment #10) > Ich habe den Fehler auf die Schnelle nicht nachstellen können (außer mit einem > kill $pid). Wenn iTalc (bzw. die python-Bindings) hin und wieder das Modul zum > Absturz bringen ist das übel. Korrekt müsste man also iTalc patchen. Ja, dafür müsste man leider den Absturz erstmal zuverlässig reproduzieren können. > sollte man trotzdem versuchen, das irgendwie zu cachen. Insgesamt würde ich den > Fehler aber lieber auf Python-Seite beheben. Da umfangreicher und > fehleranfällig, könnte man ihn auch schieben. Der Bug trat bei einigen Kunden häufiger auf, so dass die Raumverwaltung nicht wirklich benutzbar war. Ich halte ein Schieben des Bugs daher für nicht so sinnvoll.
(In reply to comment #11) > Der Bug trat bei einigen Kunden häufiger auf, so dass die Raumverwaltung nicht > wirklich benutzbar war. Ich halte ein Schieben des Bugs daher für nicht so > sinnvoll. Ich schätze, das trat auch an Ticket #2012121721001562 auf.
Den Workaround sollten wir mit UCS@school 3.1 integrieren. Das eigentliche Problem sollten wir dann zum nächsten UCS@school Update nochmal prüfen.
Fixed in ucs-school-umc-computerroom 2.0.1-1.45.201301181613 Patch wurde übernommen und funktioniert soweit.
(In reply to comment #14) > Fixed in > ucs-school-umc-computerroom 2.0.1-1.45.201301181613 > > Patch wurde übernommen und funktioniert soweit. Leider nochmal auf: Dojo1.6 Relikte: es wird dojo.hitch verwendet, und this._ und umc.dialog.alert.
Fixed in ucs-school-umc-computerroom 2.0.2-1.46.201301221027
(In reply to comment #16) > Fixed in > ucs-school-umc-computerroom 2.0.2-1.46.201301221027 Ja, die Änderungen funktionieren soweit gut. Changelog OK
UCS@school 3.1 has been released: http://forum.univention.de/viewtopic.php?f=26&t=2364 If this error occurs again, please use "Clone This Bug".