UCS-MASTER Server neu aufgebaut - LDAP-Listener läuft ewig

UCS - Univention Corporate Server
#1

Wir sind am letzten Wochenende mit unserem UCS-MASTER auf andere Hardware umgezogen. Dabei sind wir dieser Anleitung [url]https://help.univention.com/t/vollstandiger-rebuild-eines-ucs-systems-auf-neuer-hardware/113/1] gefolgt.

Es hat auch alles (fast) problemlos funktioniert, abgesehen von unterschiedlichen Gruppen-IDs und kleinen Problemen mit POSTFIX. Das haben wir aber alles in den Griff bekommen. Nur der LDAP-Listener macht uns nervös. Wir haben, wie in der Anleitung beschrieben, den Inhalt des Verzeichnisses /var/lib/univention-ldap-listener gelöscht und dann slapd, -listener und -notifier neu gestartet. Das war am Sonntag um ca. 18 Uhr - und nun ist es Mittwoch kurz nach 10 Uhr - und er läuft noch immer.

Der Rechner ist ein Dual-Xeon mit 2.8 GHz.

Hat jemand einen Tipp, wie und wo wir herausbekommen, was den Listener so beschäftigt ?
Die Synchronisation mit den anderen Slave-Servern funktioniert übrigens problemlos.

Nachsatz: Dass der Listener ewig läuft (hoffentlich) ist ja i.O. Aber dass er das mit einer CPU Usage von 99.9% macht, das macht uns nervös. Das ist doch bestimmt nicht üblich.

#2

Hallo,[quote=“willers”]Wir sind am letzten Wochenende mit unserem UCS-MASTER auf andere Hardware umgezogen. Dabei sind wir dieser Anleitung [url]https://help.univention.com/t/vollstandiger-rebuild-eines-ucs-systems-auf-neuer-hardware/113/1] gefolgt.[…]Wir haben, wie in der Anleitung beschrieben, den Inhalt des Verzeichnisses /var/lib/univention-ldap-listener gelöscht und dann slapd, -listener und -notifier neu gestartet. Das war am Sonntag um ca. 18 Uhr - und nun ist es Mittwoch kurz nach 10 Uhr - und er läuft noch immer.[…]Aber dass er das mit einer CPU Usage von 99.9% macht, das macht uns nervös. Das ist doch bestimmt nicht üblich.[/quote]
Funktioniert die LDAP-Replikation ansonsten einwandfrei? Besteht das Problem nach einem Neustart des Listeners weiterhin?

Über die Univention Baseconfig-Variable ‘ldap/debug/level’ lässt sich einstellen, wie viele Information vom Listener in die Datei /var/log/univention/listener.log geschrieben werden. Wenn Sie diesen Wert schrittweise erhöhen und nach jeder Änderung den Listener neu starten, lässt sich dann ermitteln, welches Listener-Modul für die Probleme verantwortlich ist?

Mit freundlichen Grüßen,

Wolf Wiegand

#3

Hallo Herr Wiegand,

vielen Dank für die Informationen. Also, die LDAP-Replikation funktionierte einwandfrei. Zumindest lassen die Inhalte der Dateien /var/lib/univention-ldap/notify/transaction (auf dem Master) und /var/lib/univention-ldap-listener/notifier_id (auf den Slaves) darauf schließen. Es sind auch keine Merkwürdigkeiten aufgetreten.

Ich habe nach Ihrer Antwort den Listener neu gestartet mit … restart. Der Prozess mit der 99.9% CPU usage ließ sich davon nicht beeindrucken. Er lief weiter.
Ich bin dann so vorgegangen:
[ul]Listener beendet mit … stop -> Prozess läuft noch
Notifier beendet mit …stop -> Prozess läuft noch
slapd beendet mit … stop -> Prozess läuft noch
Prozess gekilled
slapd gestartet -> alles sieht gut aus
Notifier gestartet -> noch sieht alles gut aus
Listener gestartet -> neuer Prozess mit 99.9% CPU usage
Listener wieder beendet -> Prozess läuft noch
Prozess gekilled
den Debug-Level auf 1 gesetzt
Listener gestartet -> alles sieht gut aus[/ul]
Im Log des Listeners war nichts Auffälliges zu finden. Ich habe dann den Debug-Level noch höher gesetzt und den Listener neu gestartet, aber im Log stand noch immer nichts Auffälliges. Daraufhin habe ich den Debug-Level wieder auf 0 gesetzt und den Listener ein letztes Mal neu gestartet. Es sah alles gut aus.

Allerdings war Postfix nicht davon angetan, dass ich den slapd beendet hatte. Beim Mailversand traten Fehler auf, die nach einem Neustart von Postfix aber behoben waren.

Heute morgen konnten dann einige Thin-Clients nicht mehr booten, komischerweise aber nicht alle. Die nicht bootenden Thin-Clients verursachten im Syslog einen Eintrag mit getfh failed. Wir haben angenommen, dass das mit meinen obigen Aktivitäten zusammenhängt und deshalb den Server neu gestartet. Nun ist Ruhe und alles läuft.

Mastodon