Login nach Update auf 4.1 nach einiger Zeit nicht mehr mögl

Hallo allerseits,
UCS 4.1-0 errata1

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?

Gruß,
Peter

Hallo Peter,

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.

Viele Grüße
Stephan Hendl

So nach dem das Wochenende droht und der Server allein im Keller sein Unwesen treibt,
habe ich einen stündlichen cronjob angelegt mit

1 * * * * root /usr/bin/pkill -11 -e slapd >>logdatei
2 * * * * root /usr/sbin/invoke-rc.d slapd start >>logdatei

nicht schön geht aber Erstmal.

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

Möglicherweise hilft eine Anpassung der slapd-Konfiguration:

sed -ire "/^print 'authz-regexp'$/,/^print$/d" /etc/univention/templates/files/etc/ldap/slapd.conf.d/60univention-ldap-server_acl-master
ucr commit /etc/ldap/slapd.conf
invoke-rc.d slapd restart

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.

Da ich morgen vormittag leider auch hier in der Firma weile,

werde ich die neue Idee einmal ausprobieren.

Ich kann dann morgen früh berichten.

Habe die Änderung laut dem Beitrag gemacht. Allerdings den Kernel noch nicht zurückgedatet --> slapd blieb heute Nacht wieder hängen…

Heute Nachmittag nehme ich mir mal den Kernel vor!

Auch bei mir blieb slapd heute nacht wieder stehen, trotz entfernter /etc/ldap/sasl2/slapd.conf

Code: Alles auswählen sed -ire "/^print 'authz-regexp'$/,/^print$/d" /etc/univention/templates/files/etc/ldap/slapd.conf.d/60univention-ldap-server_acl-master ucr commit /etc/ldap/slapd.conf invoke-rc.d slapd restart

Damit hat er seit gestern abend bis jetzt durchgehalten. Werde mal beobachten.

Jetzt habe ich das System mit dem bisherigen Kernel

3.16.0-ucs135-amd64

gestartet. Alles hat bisher nichts geholfen, daher mal diese Methode!

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

ich schaufle den gerade drauf :wink:

Morgen gibt es dazu eine Rückmeldung

Zumindest bootet er hier schon mal :wink:

Gruß

Uwe

Interessant,

hiermit läuft der Server seit Freitag abend durch…

[quote]Code: Alles auswählen
sed -ire “/^print ‘authz-regexp’$/,/^print$/d” /etc/univention/templates/files/etc/ldap/slapd.conf.d/60univention-ldap-server_acl-master
ucr commit /etc/ldap/slapd.conf
invoke-rc.d slapd restart[/quote]

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.

Nicht zu fassen :frowning:

Hier 30 Minuten ortsweiter Stromausfall! Ich mußte den Server herunterfahren…

Auff ein Neues. Der neueste Kernel ist aktiviert und die Kiste wieder gestartet!

[quote=“O. Bertgen”]Interessant,

hiermit läuft der Server seit Freitag abend durch…

[quote]Code: Alles auswählen
sed -ire “/^print ‘authz-regexp’$/,/^print$/d” /etc/univention/templates/files/etc/ldap/slapd.conf.d/60univention-ldap-server_acl-master
ucr commit /etc/ldap/slapd.conf
invoke-rc.d slapd restart[/quote][/quote]

Das kann auch ich bestätigen, bei mir läufts mit dieser Änderung seit Samstag ohne Hänger

Bisher jetzt fast 24 Stunden problemlose Uptime mit dem neuen Test-Kernel !

Ich denke mal, das war und ist der richtige Ansatz

[quote=“snoopy1978”][quote=“O. Bertgen”]Interessant,

hiermit läuft der Server seit Freitag abend durch…

[quote]Code: Alles auswählen
sed -ire “/^print ‘authz-regexp’$/,/^print$/d” /etc/univention/templates/files/etc/ldap/slapd.conf.d/60univention-ldap-server_acl-master
ucr commit /etc/ldap/slapd.conf
invoke-rc.d slapd restart[/quote][/quote]

Das kann auch ich bestätigen, bei mir läufts mit dieser Änderung seit Samstag ohne Hänger[/quote]

Das wars auch nicht, um 10:20 blieb slapd wieder hängen … Drehe die Änderung wieder zurück und versuche es ebenfalls mit dem neuen Kernel

root@odin:~# uname -r
4.1.0-ucs161-amd64
root@odin:~# uptime
08:33:48 up 1 day, 21:22, 1 user, load average: 0,49, 0,53, 0,50
root@odin:~#

###################

Der neue Kernel ist anscheinend der Schritt in die richtige Richtung :slight_smile: ???

Vorher lief der slapd maximal 12 Stunden störungsfrei. Jetzt sind mal knapp 2 tage herum und alles tut bisher wie es soll

Mastodon