LDAP slapd stoppt nicht ordentlich und verhindert Neustart oder Herunterfahren des Systems

UCS - Univention Corporate Server
, ,
#1

Hallo zusammen,

ich habe kürzlich von UCS 4.1.x auf 4.2.1 geupgraded und nun hängt der Domaincontroller bei einem Neustart oder auch beim Herunterfahren am Dienst “slapd” fest.

Egal wie lange man wartet, der Dienst wird nicht ordentlich beendet und das System fährt nicht herunter bzw. startet neu. Es hilft nur ein hartes ausschalten, danach funktioniert aber alles wie gewohnt.

Im Syslog findet sich zudem keine Auffälligkeit.

Ein DC Backup welcher ebenfalls aktualisiert wurde zeigt dieses Verhalten nicht.

Ist das Phänomen bekannt ?

Beste Grüße,
Ludwig

#2

Huhu,

Mir ist nichts dazu bekannt, und eine Suche im Bugtracker hat auch nichts zutage befördert.

Generell ist das einfache Ausschalten natürlich nicht gut für die Dateisystemkonsistenz. Falls es sich um einen physikalischen Server handelt, können Sie vor dem Ausschalten zumindest einen Sync der Dateisysteme erzwingen, indem Sie die magische SysRq-Kombination Alt+SysRq+s drücken (SysRq ist meist heute nicht mehr beschriftet, aber es ist die Drucken- bzw. PrintScreen-Taste). Mit Alt+SysRq+b können Sie anschließend den Kernel hart booten lassen, was den Ausschalter erspart.

Können Sie als erstes bitte mal den Inhalt des Journals eines solchen Shutdown-Versuchs zeigen? Wenn der Shutdown-Versuch z.B. gestern um 17:45 Uhr gestartet wurde und Sie dann um 17:50 Uhr resettet haben, dann z.B. mit journalctl --since '2017-08-02 17:45' --until '2017-08-02 17:50' > log.txt Passen Sie die Uhrzeiten entsprechend an.

Weiterhin können Sie das Loglevel des slapd deutlich erhöhen und dann einen Shutdown versuchen:

ucr set ldap/debug/level='trace args conns shell'
service slapd restart

Anschließend bitte wieder die Logmeldungen aus /var/log/syslog vom Prozess slapd posten.

Das Debug-Level sollten Sie anschließend unbedingt wieder leer setzen, weil mit aktivierten Meldungen ein sehr hohes Volumen an Nachrichten erzeugt wird.

Als Letztes bietet systemd selber auch Debuggingmöglichkeiten für den Shutdown.

LG,
mosu

#3

Hallo Mosu,

danke für die Infos und die Tipps.

Mittlerweile habe ich herausgefunden, dass LDAP die völlig falsche Stelle war um das Problem zu suchen.
“Stopping ldap server(s): slapd” ist die letzte Nachricht welche Univention beim Shutdown anzeigt. d.h. für alle weiteren Shutdown Vorgänge bleibt diese Meldung stehen.
Wenn man jetzt mit ESC in die Consolendarstellung wechselt sieht man die wahre Ursache. In meinem Fall handelte es sich um ein Skript in “/etc/rc.local” welches normalerweise Webdav Shares beim Systemstart mountet. Beim Herunterfahren wird das offenbar ebenfalls augeführt und läuft dann ohne Timeout für immer.

Preisfrage ist nun wieso das mit UCS 4.1 tadenlos funktioniert hat und mit UCS 4.2 plötzlich ein Problem ist ?

Vielen Dank für die Hilfe !

#4

Beim Wechsel von 4.1 auf 4.2 wurde auch vom alten sysv-Init-System auf systemd gewechselt. Das ist abhängigkeitsbasiert und verhält sich nun mal etwas anders. Vermutlich wird aufgrund irgend einer Abhängigkeit das Startscript gestartet, das rc.local ausführt.

Warum mounten Sie eigentlich die Shares über ein Script und nicht die fstab? Dafür ist sie doch da.

#5

Das Skript mountent das WebDav Share von Nextcloud eines jeden Benutzers passend in dessen Home Directory. Ich wüsste nicht wie ich das mit fstab erreichen könnte ohne für jeden Benutzer eine Zeile samt statischem Passwort zu hinterlegen ?

#6

Verstehe. Aber die Passwörter müssen ja so oder so irgendwo stehen.

Egal.

Das ist eh besser in einem regulären systemd-Service aufgehoben, denn dann kann das ordentlich parallel gestartet werden, und sie wird nicht fälschlicherweise beim Herunterfahren erneut gestartet.

Eventuell würde ich mir für so etwas systemds Automounting anschauen. Mit etwas Scripten kann man das dann bestimmt auch für eine Menge User automatisieren. Vorteil wäre, dass das Automounten eben jederzeit ausgeführt werden kann — ein statisches, einmalig ausgeführtes Script hingegen hat ja das Problem, dass neu hinzukommende User erst beim nächsten Boot berücksichtigt werden, und wenn Fehler bei Teilen der User auftreten, dann ist auch das nur durch ein manuelles Starten des Scripts zu beheben.

Mastodon