Univention Bugzilla – Bug 27228
/etc/init.d/slapd start sollte vor db4.8_recover prüfen, dass kein slapd mehr läuft.
Last modified: 2012-07-20 15:24:14 CEST
Zusätzlich wäre es gut, wenn der db4.8_stat Aufruf vor dem db4.8_recover 1. Prüfen würde, ob trotz nicht mehr laufendem slapd noch Locks auf die bdb-Umgebung des slapd gehalten werden. Ggf. kann das per db4.8_stat -Nc | sed -rn 's/([0-9]*) *Number of current locks/\1/p' erreicht werden. Falls da nicht 0 rauskommt, sollte eine Warnungsmeldung deutlich darauf hinweisen, dass es sein kann, dass der LDAP Server nicht mehr korrekt startet. In diesem Fall kann eine manuelle Recovery per slapcat notwendig sein. 2. Bei dem initialen Aufruf von "db4.8-stat -e" zusätzlich die Option -N verwendet, damit der Aufruf trotz "stale locks" oder "stale FUTEX" nicht hängen bleibt.
Hintergrund: In einem Fall trat ein FUTEX_WAIT deadlock in db4.8_stat (und slapd) auf. Nach manuellem db4.8_recover liess sich der slapd dann wieder startet, aber er antwortete nicht mehr: root@oxasex64:/var/lib/univention-ldap/ldap# univention-ldapsearch -x ldap_start_tls: Can't contact LDAP server (-1) slapcat funktionierte hingegen. Leider veröffentlicht Oracle keine Patches für db4.8.30.
*** Bug 20874 has been marked as a duplicate of this bug. ***
Template für das slapd init Skript ist entsprechend angepasst. Im Fehlerfall sieht das jetzt so aus: ============================================= root@master:/etc/init.d# /etc/init.d/slapd restart Restarting ldap server(s). Stopping ldap server(s): slapd ...done. Check database: ...WARNING. WARNING: There are stale locks in LDAP backend Berkeley DB. WARNING: If slapd does not respond, manual LDAP dump/restore may be necessary. Continuing BDB database check: ...done. Starting ldap server(s): slapd ...done. Checking Schema: ...done. ============================================= Die Formatierung der Ausgaben wurde zusätzlich verbessert: root@master:/etc/init.d# /etc/init.d/slapd restart Restarting ldap server(s). Stopping ldap server(s): slapd ...done. Check database: ...done. Starting ldap server(s): slapd ...done. Checking Schema ID: ...done. root@master:/etc/init.d# /etc/init.d/slapd start LDAP server already running. root@master:/etc/init.d# /etc/init.d/slapd stop Stopping ldap server(s): slapd ...done. root@master:/etc/init.d# /etc/init.d/slapd start Check database: ...done. Starting ldap server(s): slapd ...done. Checking Schema ID: ...done.
OK -> /etc/init.d/slapd start LDAP server already running. -> /etc/init.d/slapd restart Restarting ldap server(s). Stopping ldap server(s): slapd ...done. Check database: ...done. Starting ldap server(s): slapd ...done. Checking Schema ID: ...done. # Fehlerfall -> /etc/init.d/slapd restart Restarting ldap server(s). Stopping ldap server(s): slapd ...done. Check database: ...done. Starting ldap server(s): slapd ...done. Checking Schema ID: ... Changelog OK
(In reply to comment #5) > # Fehlerfall > -> /etc/init.d/slapd restart > Restarting ldap server(s). > Stopping ldap server(s): slapd ...done. > Check database: ...done. > Starting ldap server(s): slapd ...done. > Checking Schema ID: ... Das ist ist der Fehlerfall. -> /etc/init.d/slapd start Check database: ...WARNING. WARNING: There are stale locks in LDAP backend Berkeley DB. WARNING: If slapd does not respond, manual LDAP dump/restore may be necessary. Continuing BDB database check: ...done. Starting ldap server(s): slapd ...done. Checking Schema ID: ...done.
UCS 3.0-2 has been released: http://forum.univention.de/viewtopic.php?f=54&t=1905 If this error occurs again, please use "Clone This Bug".