Univention Bugzilla – Bug 13639
UDM Timeout zu kurz
Last modified: 2010-04-06 15:14:09 CEST
In unserer internen Umgebung wird man viel zu schnell aus dem UDM abgemeldet (30-60 Sekunden): -- root@billy:~# ucr search directory/manager/timeout directory/manager/timeout: 900 -- Ich kann es dummerweise gerade nicht reproduzieren, daher erstmal kein Log.
Ich setze den Bug auf 2.2. Mir ist das nach dem Update auf billy ebenfalls passiert, vor allem bei der Bearbeitung von Richtlinien. Ggf. hat es etwas mit der Last zu tun?
Selbst wenn ich in einer Schleife 500 Benutzer anlege kann ich das Problem nicht reproduzieren. Ich könnte mir vorstellen, dass aufgrund von einem Fehler der Prozess weggebrochen ist und dass es dann im Frontend so aussah, als ob der Timeout eingetreten ist.
Ich bekomme das nicht reproduziert. Das sollte nochmal jemand versuchen.
ich bekommen es nicht reproduziert auf einem 2.2 UCS Master * angemeldet am UDM, timeout 99999 * 100% Last erzeugt, die ganze Nacht * Anmelden am nächsten Morgen ging
falscher status
und nochmal
jetzt VERIFIED
Auf Billy ist mir das jetzt auch passiert. Ich habe mich angemeldet und habe nach Display Richtlinien gesucht, anschließend war ich mit Session-Timeout draußen. Das ganze konnte Ich 4 mal reproduzieren, beim fünften mal wollte es dann.
Created attachment 1595 [details] Log DAtei von Billy. Die Meldungen sind genau nach der Timeout Aktion, ist sonst nichts enthalten
Ich hatte nochmal auf billy geschaut, dort kann das Problem derzeit reproduziert werden. Das xmlin ist leer, nachdem ich im Richtlinienergebnis auf eine Richtlinie geklickt habe.
In univention-directory-manager.py wird die Rückgabe für dne Timeout falsch ausgewertet. Es wird davon ausgegangen, dass der Timeout eingetreten ist, wenn kein Read-Filedeskriptor anliegt, laut Doku ist das aber nur der Fall, wenn alle drei Filedeskriptoren leer sind: http://www.python.org/doc/2.5/lib/module-select.html ... When the time-out is reached without a file descriptor becoming ready, three empty lists are returned. rfds, wfds, xfds = select.select([sock], [], [], socket_timeout) - if not rfds: + if not rfds and not wfds and not xfds: break # timeout
fixed In der QA bitte auch prüfen, ob der Timeout nach einer gewissen Zeit wirklich eintritt.
Der Logout erfolgt im UDM jetzt ziemlich genau wir per UCR vorgegeben. Leider liess sich das Original-Problem auf billy für die QA gerade nicht reproduzieren. In UMC scheint sich der timout nicht genau an die Vorgabe zu halten, trotz umc/web/timeout: 120 (und UMC Neustart) scheint sie eher einen längeren Timout zu verwenden. Nach gefühlten 900 sec. erfolgt er dann aber.
ich habe die Änderung aus comment#11 auf einer 2.2 VM lokal übernommen (aber kein Update, keine Pakete installiert) der Fehler ist weiterhin aufgetreten
(In reply to comment #14) > ich habe die Änderung aus comment#11 auf einer 2.2 VM lokal übernommen (aber > kein Update, keine Pakete installiert) > > der Fehler ist weiterhin aufgetreten Tritt das nach einem Update auf die aktuelle UDM Version auch noch auf (UCS 2.2-2)? Hast du dort eigene Module implementiert?
nein, ich habe nur auf einem ucs 2.2-0 die Änderungen aus comment#11 händisch übernommen, bei der Suche nach Policies kam es dann wieder zu dem Timeout Problemen wenn der Fix aus mehr als den Änderungen aus comment#11 besteht, dann kann der Bug wieder zu ...
(In reply to comment #16) > nein, ich habe nur auf einem ucs 2.2-0 die Änderungen aus comment#11 händisch > übernommen, bei der Suche nach Policies kam es dann wieder zu dem Timeout > Problemen > > wenn der Fix aus mehr als den Änderungen aus comment#11 besteht, dann kann der > Bug wieder zu ... Kannst du das bitte prüfen?
ich habe nun dem kompletten Patch aus -> svn diff -c 9849 svn+ssh://fbotner@billy.knut.univention.de/var/svn/dev/branches/ucs-2.2/ucs/management/univention-directory-manager in ein ucs2.2-0 händisch übernommen (jedoch kein Update gemacht) bei der Suche nach Policies kam dann trotzdem ab und zu der Timeout nebenbei wurde das System mit -> while true; do echo "jkgjkgj"; done -> grep -r kdgfkdgffdsflsdh / -> while true; do ldapsearch -x; done beschäftigt (nur bei höherer Systemlast scheint das Problem aufzutreten) soll ich das nochmal mit einem ordentlich geupdateten System probieren?
(In reply to comment #18) > soll ich das nochmal mit einem ordentlich geupdateten System probieren? Ja, bitte.
Das System wurde nun mit univention-updater auf ucs2.2-2 aktualisiert. Trotzdem kam es bei der Suche nach Policies wieder zum Timeout. (nebenbei wieder -> while true; do echo "jkgjkgj"; done -> grep -r kdgfkdgffdsflsdh / -> while true; do ldapsearch -x; done)
Ohne die automatische Suche und ohne hohe Systemlast konnte ich das Problem nicht reproduzieren.
Im Zusammenhang mit Ticket 2009092410000145 wieder berichtet. Dort waren die Probleme seit dem Import von ~700 Usern auch in der Navigation zu beobachten, dabei wurden in den Ergebnislisten zum Teil die "Seitenzahlen" unten wohl nicht mehr angezeigt. Evtl. wird die Datenmenge im XML oder HTML einfach zu gross?
*** Bug 1951 has been marked as a duplicate of this bug. ***
Ich schaffe es auch unter Last auf einem UCS 2.3 System nicht das Problem zu reproduzieren. Aktuell kann es einigermaßen zuverlässig auf billy reproduziert werden, aber nur wenn die UCR Variable directory/manager/web/modules/autosearch auf yes gesetzt wird. Klick auf Richtlinien, wenn dann der Timeout noch nicht kommt, dann sollte dieser beim Klick auf das erste Richlinienobjekt kommen. Nicht immer, aber in ungefähr zwei von drei Fällen. Das XML wird 135 KB groß und ist zwischen beiden Fällen absolut identisch.
write(2, "Traceback (most recent call last):\n", 35) = 35 write(2, " File \"/usr/share/univention-directory-manager/uniconf/univention-directory-manager.py\", line 190, in ?\n", 105) = 105 write(2, " ", 4) = 4 write(2, "main(sys.argv)\n", 15) = 15 write(2, " File \"/usr/share/univention-directory-manager/uniconf/univention-directory-manager.py\", line 185, in main\n", 108) = 108 write(2, " ", 4) = 4 write(2, "session.finishRequest(number)\n", 30) = 30 write(2, " File \"/usr/share/univention-webui/modules/requests.py\", line 450, in finishRequest\n", 85) = 85 write(2, " ", 4) = 4 write(2, "self.saver_history[number]=cPickle.dumps(self.save)\n", 52) = 52 write(2, "RuntimeError", 12) = 12 write(2, ": ", 2) = 2 write(2, "dictionary changed size during iteration", 40) = 40 write(2, "\n", 1)
Die Excpetion kann relativ einfach abgefangen werden. Das eigentliche Problem ist damit allerdings nicht gelöst. Es scheint so zu sein, dass self.save während der Zeit verändert wird, vermutlich durch einen anderen Thread.
fixed Für das generelle Problem habe ich einen neuen Bug eröffnet: Bug #15940
Wäre es ggf. sinnvoll, ein tmpsave = copy.deepcopy(self.save) dort einzubauen und dann tmpsave zu pickeln?
(In reply to comment #28) > Wäre es ggf. sinnvoll, ein > tmpsave = copy.deepcopy(self.save) > dort einzubauen und dann tmpsave zu pickeln? Dann bricht er beim deepcopy mit der gleichen Exception ab.
Ich kann es jetzt nicht mehr reproduzieren. Changelog Eintrag ist vorhanden.
UCS 2.3 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".
*** Bug 6739 has been marked as a duplicate of this bug. ***
Created attachment 2373 [details] Patch für UCS 2.2-2 Dieser Patch setzt den Fix unter UCS 2.2-2 um. # patch -p0 < bug13639-request.patch