Hallo Herr Gohmann,
das Problem ist gerade eben wieder aufgetreten.
Ich starte gleich den AD-Master einmal neu und erstelle Ihnen Ihre Datei.
Geplant bei uns war, das wir zum Jahreswechsel zwischen Weihnachten und Neujahr auf UCS umsteigen, also noch können wir am System probieren 
MfG,
Oliver Bertgen
Hallo Herr Gohmann,
hier die ID: upload_hGo0xS.gz -> ldap.tgz
upload_5tiTm5.asc -> ldif
Viele Grüße,
Oliver Bertgen
Hallo Herr Gohmann,
das gleiche Problem auch hier im Testsystem ohne weitere Benutzerinteraktionen. Soll ich auch ein slapcat bereitstellen?
Viele Grüße und viel Erfolg
Stephan Hendl
Hier dasselbe.
Seit dem letzten kompletten Neustart lief das System jetzt etwa 14 Stunden durch.
Ein invoke-rc slpad restart hat nicht mehr funktioniert. ich musste den slapd Prozeß mit “kill-9” abschießen, dann war es ohne Server-Neustart wieder OK
upload_VccRzr.zip
Wir haben gerade aktualisierte Pakete mit einer Vorabversion des Fixes veröffentlicht. Diese können durch einbinden der Komponente “glibc” und einem Upgrade eingespielt werden:
ucr set repository/online/component/glibc=true \
repository/online/component/glibc/unmaintained=true
univention-upgrade
invoke-rc.d slapd restartDa wir intern bisher kein System haben auf dem das Problem reproduziert werden kann freuen wir uns natürlich über Rückmeldungen von Testern, wie sich das System mit den angepassten Paketen verhält. Ein offizielles errata-Update wird so schnell wie möglich veröffentlicht.
Wie hier vorgeschlagen:
habe ich vor 2 Tagen diese Datei gelöscht (bzw. umbenannt) und seitdem ist das Problem nicht mehr aufgetreten. Dies werde ich nun zurück nehmen und diesen Fix probieren
[quote=“Best”]Wir haben gerade aktualisierte Pakete mit einer Vorabversion des Fixes veröffentlicht. Diese können durch einbinden der Komponente “glibc” und einem Upgrade eingespielt werden:
ucr set repository/online/component/glibc=true \
repository/online/component/glibc/unmaintained=true
univention-upgrade
invoke-rc.d slapd restart[/quote]
Guten Morgen,
Server hatte sich über Nacht wieder aufgehangen.
Den Lösungsvorschlag habe ich soeben eingespielt.
Ich denke spätestens morgen früh kann ich erste Infos mitteilen, bzw. schon eher, wenn er sich wieder aufgehangen haben sollte.
Mit freundlichem Gruß,
Oliver Bertgen
Moin, Fix eingespielt.
Hallo,
ich habe die betroffenen Systeme ebenfalls upgedated und lasse wissen ob es funktioniert 
VIELEN Dank erst einmal für die schnelle Reaktion
Uwe
Hallo UCS-Team,
melde mich schon eher, was bedeutet, Server hat sich trotz Patch wieder aufgehangen …
Dazu eine Anmerkung:
Bei mir hatte sich unser hauseigener Server auch VOR dem Update auf die 4.1 schon am 15.11. einmal aufgehangen. Dasselbe Symptom. Damals wurde er per RESET neu gestartet da ja keiner wußte was da geschehen ist…
Vielleicht ist das gar kein 4.1 spezifisches Problem, sondern es existiert als “Schlafendes Problem” schon länger ???
[quote=“O. Bertgen”]Hallo UCS-Team,
melde mich schon eher, was bedeutet, Server hat sich trotz Patch wieder aufgehangen …[/quote]
Dem kann ich mich anschließen, auch ich habe den glibc Patch wie angegeben installiert, der LDAP Server hat sich vor 10 Minuten jedoch leider wieder aufgehangen. Glücklicherweise hatte ich zu diesem Zeitpunkt gerade noch eine root Session offen und vor wenigen Tagen wie hier beschrieben:
alles für das Erstellen von core-dumps vorbereitet.
Dies habe ich dann per kill -11 auch getan. Daraufhin wurden unter /var/tmp/core/ eine Reihe von
core-dhcpd-* und core-smbd-* angelegt (warum auch immer da keine core-slapd-* dabei sind, was ich eigentlich erwartet hätte :S )
Die dumps habe ich gepackt und hier hochgeladen:
upload.univention.de, zu finden unter der ID: upload_1izJNM.gz
Der slapd Prozess war daraufhin beendet, er konnte problemlos per
invoke-rc.d slapd start
gestartet werden, das Problem damit sofort behoben.
Keine Ahnung, ob das irgendwie relevant ist, aber mit ist aufgefallen, dass wenige Minuten vorher diese cron-jobs gestartet worden sind:
Nov 26 16:10:02 server /USR/SBIN/CRON[11333]: (root) CMD ( /usr/lib/univention-virtual-machine-manager-daemon/uvmmd-check.sh)
Nov 26 16:10:02 server /USR/SBIN/CRON[11349]: (root) CMD ( if [ -x /usr/sbin/univention-umount-homedirs ]; then /usr/sbin/univention-umount-homedirs; fi)
Nov 26 16:10:02 server /USR/SBIN/CRON[11379]: (root) CMD (/usr/sbin/jitter 60 /usr/share/univention-samba4/scripts/sysvol-sync.sh >>/var/log/univention/sysvol-sync.log 2>&1)
Nov 26 16:10:02 server /USR/SBIN/CRON[11398]: (root) CMD (if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg.cfg ] && [ -d "$(grep '^[[:space:]]*[^#]*[[:space:]]*WorkDir' /etc/mrtg.cfg | awk '{ print $NF }')" ]; then mkdir -p /var/log/mrtg ; env LANG
=C /usr/bin/mrtg /etc/mrtg.cfg 2>&1 | tee -a /var/log/mrtg/mrtg.log ; fi)
Hallo,
ja, der erste Versuch hat leider nicht geklappt. Wir haben das Problem nun erkannt und ein Programm, dass es reproduzierbar macht.
Weitere Infos hier: forge.univention.org/bugzilla/s … =40059#c19.
Vielen Dank für die Unterstützung bei der Bereitstellung von Informationen.
Wir können das Problem mit dem Testprogramm mittlerweile reproduzieren und konnten auch nachvollziehen, dass das Problem schon mit UCS 4.0 auftreten konnte. Allerdings scheint es in UCS 4.1 eine Änderung zu geben, die das Problem häufiger auftreten lässt.
Zwei Ideen:
Es könnte an Docker liegen. Tritt das Problem auch noch in der Häufigkeit auf, wenn Docker gestoppt ist?
/etc/init.d/docker stop
Tritt das Problem auch auf, wenn die SASL Konfiguration überschrieben wird?
echo >/etc/ldap/sasl2/slapd.conf
/etc/init.d/slapd restart
Wenn SAML nicht genutzt wird und keine Docker Container laufen (bisher gibt es noch keine Docker Apps im App Center), dann sollten beide Änderungen problemlos testbar sein.
Hallo
Server ist jetzt trotz patch wieder stehen geblieben
ich hatte extra ein root Terminal offen gelassen um Notfalls zu reagieren.
Das tat ich mit kill ldap und invoke-rc.d slapd start
[…] Check database: …[info] WARNING.
[info] WARNING: There are 29 stale locks in LDAP backend Berkeley DB (version 5.1.29).
[info] WARNING: If slapd does not respond, manual LDAP dump/restore may be necessary.
[ ok ] Continuing BDB database check: …done.
[ ok ] Starting ldap server(s): slapd …done.
[ ok ] Checking Schema ID: …done.
Anmeldung ist jetzt wieder möglich.
Der Docker ist nun auch still
/etc/init.d/docker stop
Nun hoffe ich das Morgen der Server noch läuft.
Gute Nacht
Ok
das ging schnell keine 15min und slapd war wieder durch.
Beide male habe ich mit owncloud gespielt.
Der docker wars dann wohl nicht.
So ich hab noch weiter gespielt mit owncloud 20 mal eingeloggt, nix passiert.
Findet das nur Nachts statt ?
Läuft da irgendein backup ?
Diese Datei zu löschen war ja vor einigen Tagen schon einmal Thema hier, weshalb das mit das Erste war, was ich probiert habe. Dies scheint auch zu helfen, denn während die Datei entfernt war, trat das Problem ca. 2 Tage lang bei mir nicht mehr auf. Danach hatte ich den ersten Lösungsversuch bzgl. glibc - Update probiert und dazu auch diese Datei wieder hergestellt. Dann hat es keine 12 Stunden gedauert und slapd blieb stehen…
Wir haben folgendes im Test:
Einen cronjob, der zu jeder Stunde zu einer “krummen” Uhrzeit den “slpad” neu startet
Seither läuft der Server erst einmal fast 2 Tage durch!
Zufall oder nicht ist hier die Frage…
[quote]Gohmann hat geschrieben:
2. Tritt das Problem auch auf, wenn die SASL Konfiguration überschrieben wird?
echo >/etc/ldap/sasl2/slapd.conf
/etc/init.d/slapd restart [/quote]
Habe ich heute morgen umgesetzt. Werde berichten, ob es etwas nützt.
MfG
O. Bertgen
Bei uns blieb der hauseigene Server etwa 8 Stunden nach dem Löschen der sasl2 Konfigurationsdatei trotzdem hängen
Das war es bei uns also erst einmal nicht.
Jetzt machen wir bei einem Server den Versuch mit deaktiviertem Docker UND leerer /etc/ldap/sasl2/slapd.conf
Ich werde berichten