Univention Bugzilla – Bug 12331
Im Fehlerfall wird die Transaction-ID auf 0 gesetzt
Last modified: 2011-04-04 15:46:23 CEST
Auftreten bei einem Kunden: In der /var/lib/univention-ldap/notify/transaction standen am Ende viele Einträge bei denen die ID 0 war. In der /var/lib/univention-ldap/last_id war -1 eingetragen. Dadurch werden die Änderungen nicht mehr repliziert. Das Problem kann damit zusammenhängen, dass der slapd in dem Zeitraum auch ein Problem mit 'Too many open files' hatte. Diesen Zustand kann man leider nicht im Log erkennen, da die Logs aus dem Overlay-Modul bei LogLevel nicht geschrieben werden. Beheben liess sich das Problem durch die Korrektur der transaction und last_id Datei (notifier und slapd wurden vorher angehalten).
Erneut aufgetreten an: 2009042710000247 Die Ursache ist die gleiche: "durch Löschen der Datei /var/lib/univention-ldap/notify/transaction.index und anschließendem Neustart werden wieder korrekte Transaktions-IDs generiert."
Die Ursache könnte mit OL24 seit UCS 2.3 behoben sein (epoll).
(In reply to comment #2) > Die Ursache könnte mit OL24 seit UCS 2.3 behoben sein (epoll). Meines Wissens ist das nochmal auf einem 2.3 System aufgetreten.
(In reply to comment #3) > (In reply to comment #2) > > Die Ursache könnte mit OL24 seit UCS 2.3 behoben sein (epoll). > > Meines Wissens ist das nochmal auf einem 2.3 System aufgetreten. Ja, das ist bei Kunde 07142 aufgetreten.
an 2009042710000247 im Zusammenhang mit "too many open files" wieder aufgetreten.
(In reply to comment #5) > an 2009042710000247 im Zusammenhang mit "too many open files" wieder > aufgetreten. Falsche ID, gemeint war 2011022110002059
Created attachment 3061 [details] Prototypisches Skript zur Korrektur der transaction-Datei
Laut Ticket 2009042710000247 ist die last_id auf dem Master -1. Da diese Datei von translog overlay geschrieben wird, ist der Fehler vermutlich im Overlay bzw. im Zusammenspiel mit dem Fehlerzustand des slapd zu suchen. https://hutten.knut.univention.de/mediawiki/index.php?title=Arvid_memo/Listener#Nagios_Checks
Zur Behebung des "too many open files" Fehlerzustands in OpenLDAP gibt es jetzt Bug 21638 als Vorschlag.
Es scheint so zu sein, dass das translog overlay 1. versucht die last_id Datei zu öffnen und dann bei Fehler 2. versucht /var/lib/univention-ldap/notify/transaction zu öffnen. 3. bei erneutem Fehler den Wert -1 als last_id verwendet. 4. falls lastid nicht > -1 den String "<TransID> %s %c\n" nach /var/lib/univention-ldap/listener/listener schreibt und lastid dann nicht erhöht (ausser bei modrdn). 5. die lastid in die Datei /var/lib/univention-ldap/last_id sichert (Symptom). Der Notifier liest dann per sscanf(s, "%ld", &id); die ID und das liefert bei s="<TransID>" eine 0, die dann wiederholt im transaction log landet.
Kurzanleitung zur Behebung des Problems: - LDAP-Server, Notifier und Listener anhalten - nach /var/lib/univention-ldap/notify wechseln - angehängtes Skript aufrufen - "transaction.modified" ist dann die reparierte transaction, Datei entsprechend umbenennen und die Berechtigungen wieder setzen: # chown listener:"DC Backup Hosts" transaction # chmod o-rwx transaction - Datei "transaction.index" löschen - Datei /var/lib/univention-ldap/last_id korrigieren (letzte ID der Transaction) - LDAP-Server, Notifier und Listener starten transaction immer auf Konsistenz prüfen, es kann noch zu Überschneidungen bei der Vergabe der IDs kommen.
Mit UCS 2.4-0 ist durch die Anpassung für Bug 17705 der ulimit Wert für offene Filedescriptoren per UCR-Variable ldap/maxopenfiles auf 4096 erhöht worden. Für UCS 3.0 wird sie über Bug 21640 weiter auf 8096 (oder mehr) erhöht. Die Möglichkeiten, über UCR die Skalierbarkeit des OpenLDAP-Servers zu erhöhen wird über den Doku-Bug 21641 zusätzlich zum SDB auch im UCS Performance Guide dokumentiert. Weitergehende Anpassungen. z.B. in den Bereichen * Fehlerbehandlung des translog Overlay * File-Handling von last_id * Schreibzugriffe auf transaction log scheinen im Moment nicht sinnvoll: * LDAP operation rollback scheint in translog.on_response nicht möglich zu sein * Verbessertes Filehandling von last_id zieht ggf. schwerwiegenderen Fehlerzustand im 'listener' translog file nach sich, wenn das dann (statt last_id) nicht mehr geschrieben werden kann. * Im Notifier die transaction ID schlicht weiterzuzählen wenn die ID kein numerischer Wert mehr ist klingt ein bisschen nach split brain. Daher wontfix.
OK, auf einem 2.4-1 Standard Master ist das maxopenfiles Limit für den slapd auf 4096 gesetzt. -> grep "open files" /proc/$(pidof slapd)/limits Max open files 4096 4096 files
UCS 2.4-2 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".