Bug 12331 - Im Fehlerfall wird die Transaction-ID auf 0 gesetzt
Im Fehlerfall wird die Transaction-ID auf 0 gesetzt
Status: CLOSED WONTFIX
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 2.1
All All
: P2 critical (vote)
: UCS 2.4-2
Assigned To: Arvid Requate
Felix Botner
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-06 18:36 CEST by Andreas Büsching
Modified: 2011-04-04 15:46 CEST (History)
6 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
Prototypisches Skript zur Korrektur der transaction-Datei (369 bytes, text/x-python)
2011-02-22 09:12 CET, Ingo Steuwer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Büsching univentionstaff 2008-10-06 18:36:43 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).
Comment 1 Janis Meybohm univentionstaff 2009-04-28 11:19:17 CEST
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."
Comment 2 Arvid Requate univentionstaff 2009-12-23 14:54:56 CET
Die Ursache könnte mit OL24 seit UCS 2.3 behoben sein (epoll).
Comment 3 Stefan Gohmann univentionstaff 2010-04-07 20:35:06 CEST
(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.
Comment 4 Moritz Muehlenhoff univentionstaff 2010-04-08 08:44:40 CEST
(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.
Comment 5 Ingo Steuwer univentionstaff 2011-02-22 09:10:07 CET
an 2009042710000247 im Zusammenhang mit "too many open files" wieder aufgetreten.
Comment 6 Ingo Steuwer univentionstaff 2011-02-22 09:10:47 CET
(In reply to comment #5)
> an 2009042710000247 im Zusammenhang mit "too many open files" wieder
> aufgetreten.

Falsche ID, gemeint war 2011022110002059
Comment 7 Ingo Steuwer univentionstaff 2011-02-22 09:12:15 CET
Created attachment 3061 [details]
Prototypisches Skript zur Korrektur der transaction-Datei
Comment 8 Arvid Requate univentionstaff 2011-02-22 11:54:23 CET
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
Comment 9 Arvid Requate univentionstaff 2011-02-22 12:01:09 CET
Zur Behebung des "too many open files" Fehlerzustands in OpenLDAP gibt es jetzt Bug 21638 als Vorschlag.
Comment 10 Arvid Requate univentionstaff 2011-02-22 12:42:40 CET
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.
Comment 11 Ingo Steuwer univentionstaff 2011-02-22 16:07:17 CET
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.
Comment 12 Arvid Requate univentionstaff 2011-02-22 17:14:10 CET
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.
Comment 13 Felix Botner univentionstaff 2011-03-03 15:47:12 CET
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
Comment 14 Sönke Schwardt-Krummrich univentionstaff 2011-04-04 15:46:23 CEST
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".