Seit gestern mittag hatten wir schon zweimal den Fall, dass der UCS zu 100% ausgelastet war. Als Ursache zeigt der Befehl top den Prozess ‘nscd’ mit nahezu 100% CPU-Last an. Im Syslog wird dazu haufenweise ‘nss_ldap: ldap_start_tls failed: Timed out’ angezeigt. Der Dienst ‘nscd’ ließ sich auch nicht mit einem ‘service nscd stop’ beenden. Erst ein Reboot, der aber mehrere Minuten gebraucht hat, um durchgeführt zu werden, hat das Problem behoben.
Was kann die Ursache sein, dass nscd scheinbar Amok läuft?
das Problem hatten/haben wir hier auch. Der nscd fragt den LDAP und wenn der nicht antwortet kommt er nicht zurück und “frisst sich fest”. Nach einem kill/start des slapd und restart des nscd sollte dieser wieder ordentlich arbeiten.
Eine baldige echte Lösung würde ich mir wünschen ,der Server ist im produktiven Einsatz.
Welche Nebenwirkungen das stündliche killen für bestehen Verbindungen hat kann ich nicht sagen.
Grüße
Wenn auf dem System noch der Linux-Kernel aus UCS 4.0 installiert ist empfehlen wir diesen zu booten.
Erfahrene Anwender können diesen natürlich nachträglich aus den UCS 4.0 Paketquellen installieren.
Mit dem Kerne 4.1 habe ich bei einem Kunde auch noch zusätzlichen Streß bekommen:
Nach dem Update auf 4.1 ließ sich der Server mit dem Kernel 4.1 nicht mehr starten. Auch nicht im Wiederherstellungsmodus.
Nach der Auswahl im Startmenü kommt noch:
“Please wait”
dann nach ca. 2 Minuten läuft eine Fehlermeldung über den Schirm und wiederholt sich. Ich habe den genauen Wortlauf nicht mehr im Sinn, aber etwas wie
probing PCI Device…
Der Server direkt daneben hat bis auf den RAID Controller die identische Hardware und startet problemlos. Ich habe dann Folgendes gemacht:
Kernel neu installiert, initrd neu gemacht, Grub neu installiert
NICHTS hilft, Server bootet nicht.
Wenn ich aber von einer Debian-Rescue CD anstartet und von dort das UCS auf der Platte starte ist alles ok und der Server startet problemlos mit dem Kernel 4.10! man kann dann auch problemlos mit ihm arbeiten. Alles funktioniert wie gewünscht. Nur botten kann er den Kernel 4.10 nicht.
Wenn ich im GRUB Menü einen der älteren Kernel “3.16.0-ucs135-amd64” auswähle dann startet und funktioniert der Server ebenfalls problemlos.
Noch etwas zum Thema slapd:
Ich habe bei unserem hauseigenen Server ebenfalls das System mit dem Kernel “3.16.0-ucs135-amd64” gestartet. Und bisher kein Aufhängen des slapd Prozesses mehr gehabt!
Mir scheint fast, der Kernel 4.10 hat noch seine Tücken ??
Ich habe jetzt eine ersten Test Kernel gebaut. Der wurde allerdings noch nicht ausreichend geprüft, sondern nur sehr oberflächlich. Zumindest das Testprogramm läuft damit durch.
Bisher gibt es den Kernel nur für amd64, wer den Kernel testen möchte:
ucr set repository/online/component/glibc=true \
repository/online/component/glibc/unmaintained=true
univention-install linux-image-4.1.0-ucs161-amd64
Jetzt hat der Kernel “4.1.0-ucs161-amd64” knapp 11 Stunden Betriebszeit. Bisher alles OK, spätestens nach 12-14 Stunden hat sich bisher der slapd weggehängt. Beobachten wir weiter…
Kurzer Zwischenstand bei uns. Es gab seit dem letzten Hängenbleiden von nscd am Freitag morgen keine Probleme mehr. Ich habe aber auch bis dato keine Änderungen vorgenommen.
???