Univention Bugzilla – Bug 20841
slapd hängt mit 100% CPU
Last modified: 2013-11-19 06:44:17 CET
Auf UCS 2.4-0 und UCS 2.4-1 Master mit 2.6.32-ucs11-amd64 (QA-VM /Univention GmbH/Single/UCS.2-4-0.Master.amd64.tar.gz) hängt der slapd manchmal mit 100% CPU wenn ein bestimmtest ucs-test-Skript ausgeführt wird. Reproduzieren: Folgende Pakete zum Testen installieren ucs-test-framework 1.3.301-1 ucs-test-libs 1.3.301-1 ucs-test-udm-containers 1.3.301-1 Alle Skripte bis auf 34removecontainerrecursive_ou löschen: # rm /usr/share/ucs-test/scripts/63_udm-containers/3{{0..3},{5..9}}* So lange das Testskript ausführen, bis es hängen bleibt (slapd taucht mit 100% CPU in top auf): # while ucs-test -s udm-containers ; do : ; done
Created attachment 2870 [details] syslog(ldap/debug/level=256) von einem Auftreten des Fehlers
Created attachment 2871 [details] syslog(ldap/debug/level=256) von einem Auftreten des Fehlers Wenn der slapd hängt, kommt auch ein "ldapsearch -xLLL" nicht ohne SIGINT zurück (conn=1293 im Log)
Created attachment 2872 [details] syslog(ldap/debug/level=256) von einem Auftreten des eines segfaults Einmal hat das gleiche Skript auch einen segfault verursacht
Das scheint nur aufzutreten, wenn das "RESULT" von der op=20 nach dem Start einer neuen Operation (op=21 DEL) im Log steht: conn=9635 op=20 DEL conn=9635 op=21 DEL conn=9635 op=20 RESULT
Zitat aus ITS#5715: > This bug is typical of loading a libsasl2 module (libsasldb) built with > a Berkeley DB version different from the one slapd was built with, or > loading a libsasl2 module built with a different version of libsasl2 > than the one slapd was built with. Can you check?
(In reply to comment #5) > Zitat aus ITS#5715: > > > This bug is typical of loading a libsasl2 module (libsasldb) built with > > a Berkeley DB version different from the one slapd was built with, or > > loading a libsasl2 module built with a different version of libsasl2 > > than the one slapd was built with. Can you check? Dies ist vermutlich relevant für den Segfault in comment 3
Created attachment 2873 [details] syslog(ldap/debug/level=257) von einem Auftreten des Fehlers
Created attachment 2874 [details] syslog(ldap/debug/level=257) von einem Auftreten des Fehlers
Eventuell war das auch die Ursache für Bug #16211 (die Symptome gleichen sich)
Created attachment 2876 [details] slapcat Ich hänge noch das LDAP der Testmaschine an - eventuell tritt das nur bei größeren Benutzerzahlen wie diese sie hat auf.
Created attachment 2880 [details] Testskript was den gleichen Fehler erzeugt
Created attachment 2881 [details] Testskript was den gleichen Fehler erzeugt Diese beiden Testskripte erzeugen den Fehler sehr viel schneller.
db 4.7.25-6 wurde mit den configure Optionen "--enable-posixmutexes --with-mutex=POSIX/pthreads" neu gebaut, die von den OpenLDAP Entwicklern empfohlen sind. Dann wurde openldap ebenfalls neu (gegen db) gebaut. Damit scheint das Problem deutlich seltener aufzutreten, weg ist es aber leider noch nicht. Gefühlt scheint es unter amd64 seltener aufzutreten als unter i386. Die bdb-Patches für 4.7 sind bis auf http://download.oracle.com/berkeley-db/patches/db/4.7.25/patch.4.7.25.4 (bei dem es nur um Replikation geht) alle im Debian-Paket enthalten. Ggf. hilft aktuell dann nur, GDB traces für das OpenLDAP Projekt bereitzustellen, da es einige ähnliche, aber bisher keine sachdienlichen Fehlerberichte gibt. Die Position von OpenLDAP scheint hier in die Richtung zu gehen, diese 100% CPU Zustände als Symptome von Bugs im bdb-Code zu betrachten.
Ok, gerade nochmal getestet, da ging es.. also lieber schnell zu mit dem Bug :-) Bei der QA: apt-get install db4.7-util libdb4.7 slapd
leider ... kann ich das mit dem Test-Skript von Janek ----------------------------------------------------------------- #!/bin/bash eval "$(univention-config-registry shell ldap/base)" while echo "$RANDOM" do echo "dn: ou=lvl1,$ldap_base objectClass: top objectClass: organizationalUnit ou: test description: zum Testen dn: ou=lvl2,ou=lvl1,$ldap_base objectClass: top objectClass: organizationalUnit ou: test description: zum Testen dn: ou=lvl3,ou=lvl2,ou=lvl1,$ldap_base objectClass: top objectClass: organizationalUnit ou: test description: zum Testen dn: cn=lock,ou=lvl3,ou=lvl2,ou=lvl1,ou=test,$ldap_base objectClass: top objectClass: lock lockTime: $RANDOM cn: lock " | ldapadd -x -D "cn=admin,$ldap_base" -w "$(cat /etc/ldap.secret)" ldapdelete -x -D "cn=admin,$ldap_base" -w "$(cat /etc/ldap.secret)" \ -r "ou=lvl1,$ldap_base" done ----------------------------------------------------------------- noch reproduzieren. Der slapd ist dann ziemlich schnell bei 100%CPU und meldet sich nicht mehr. Das bleibt auch so bis man ihn neu startet. Auf amd64 und i386 ucs2.4-2 i386: ii db4.7-util 4.7.25-6.7.20110131 Berkeley v4.7 Database Utilities ii libdb4.7 4.7.25-6.7.20110131 Berkeley v4.7 Database Libraries ii slapd 2.4.23-1.47.2011022 OpenLDAP server (slapd) amd64: ii db4.7-util 4.7.25-6.7.20110131 Berkeley v4.7 Database Utilities ii libdb4.7 4.7.25-6.7.20110131 Berkeley v4.7 Database Libraries ii slapd 2.4.23-1.47.2011022 OpenLDAP server (slapd)
Ein Bugreport mit gdb traces ist jetzt upstream, siehe URL.
Tritt auch weiterhin mit db 4.8.24 auf. Das mit uupdate erstellte OpenLDAP 2.4.24 Paket mit debian Patches war nach dem Paketbau nicht lauffähig, auch nach mehreren Versuchen nicht.
Für diesen Bug wurde bis dato keine Ursache/Lösung gefunden. Bei einer neuen upstream-Version sollte das nochmal getestet werden und der Bugreport im OpenLDAP Issue Tracking System aktualisiert werden (siehe URL).
Das Problem scheint mit Bug 22468 gefixed zu sein (OpenLDAP 2.4.25 mit libdb4.8)
Leider noch nicht. Auf einem UCS 3.0 mit -> apt-cache show slapd| grep Depen| grep libdb4.8 Depends: libc6 (>= 2.4), libdb4.8 (>= 4.8.30), libldap-2.4-2 (= 2.4.25-1.55.201107131436), libltdl7 (>= 2.2.6b), libperl5.10 (>= 5.10.1), libsasl2-2, libslp1, libssl0.9.8 (>= 0.9.8m-1), libwrap0 (>= 7.6-4~), unixodbc (>= 2.2.11), coreutils (>= 4.5.1-1), psmisc, perl (>> 5.8.0) | libmime-base64-perl, adduser, lsb-base (>= 3.2-13) -> ldd /usr/sbin/slapd linux-gate.so.1 => (0xb7878000) libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0xb781c000) liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0xb7810000) libdb-4.8.so => /usr/lib/libdb-4.8.so (0xb76a9000) libodbc.so.1 => /usr/lib/libodbc.so.1 (0xb7642000) libslp.so.1 => /usr/lib/libslp.so.1 (0xb7632000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb761b000) libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb75d1000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7478000) libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb7446000) libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xb7432000) libltdl.so.7 => /usr/lib/libltdl.so.7 (0xb742a000) libwrap.so.0 => /lib/libwrap.so.0 (0xb7422000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7409000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb72c2000) libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb72ab000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb72a7000) libz.so.1 => /usr/lib/libz.so.1 (0xb7293000) /lib/ld-linux.so.2 (0xb7879000) ii slapd 2.4.25-1.55.201107131436 OpenLDAP server (slapd) ii libdb4.8 4.8.30-2.4.201106160855 Berkeley v4.8 Database Libraries [runtime] führt das Testscript aus comment #15 nach einiger Zeit zu einem unbenutzbaren slapd. strace sagt dann folgendes: -> strace -f -tt -p $(pidof slapd) [pid 6870] 23:18:24.736076 sched_yield() = 0 [pid 6870] 23:18:24.736106 sched_yield() = 0 [pid 6870] 23:18:24.736136 sched_yield() = 0 [pid 6870] 23:18:24.736166 sched_yield() = 0 [pid 6870] 23:18:24.736196 sched_yield() = 0 [pid 6870] 23:18:24.736226 sched_yield() = 0 [pid 6870] 23:18:24.736255 sched_yield() = 0 [pid 6870] 23:18:24.736285 sched_yield() = 0 [pid 6870] 23:18:24.736315 sched_yield() = 0 [pid 6870] 23:18:24.736345 sched_yield() = 0 [pid 6870] 23:18:24.736375 sched_yield() = 0 [pid 6870] 23:18:24.736405 sched_yield() = 0 [pid 6870] 23:18:24.736435 sched_yield() = 0 Mit ldap/debug/level=4 (heavy trace debugging (function args) sieht man folgendes in der syslog: Jul 14 23:17:20 master slapd[6866]: OVER: get_last_id Jul 14 23:17:20 master slapd[6866]: OVER: Found ID "38283" Jul 14 23:17:20 master slapd[6866]: connection_get(21) Jul 14 23:17:20 master slapd[6866]: ==> bdb_delete: ou=lvl1,dc=drei Jul 14 23:17:20 master slapd[6866]: => bdb_entry_get: ndn: "cn=domain admins,cn=groups,dc=drei" Jul 14 23:17:20 master slapd[6866]: => bdb_entry_get: oc: "univentionGroup", at: "uniqueMember" Jul 14 23:17:20 master slapd[6866]: dnMatch 18 ^I"uid=administrator,cn=users,dc=drei" ^I"cn=admin,dc=drei" Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 @ou=lvl1,dc=drei Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 %dc=drei Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [0096defd] Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [9bee355f] Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [5968d4cc] Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [b264ef9b] Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [24fdcc29] Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [87a5702a] Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [495c35c8] Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [49ee71e5] Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [f76e3935] Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [afa18bf9] Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [ca659a4d] Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [a3cdd530] Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [74a3ef4d] Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [c4095910] Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [f14f3e24] Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [f6b85387] Jul 14 23:17:20 master slapd[6866]: connection_get(13) Jul 14 23:17:20 master slapd[6866]: SRCH "ou=lvl3,ou=lvl2,ou=lvl1,dc=drei" 0 0 Jul 14 23:17:20 master slapd[6866]: 0 300 0 Jul 14 23:17:20 master slapd[6866]: filter: (objectClass=*) Jul 14 23:17:20 master slapd[6866]: attrs: Jul 14 23:17:20 master slapd[6866]: * Jul 14 23:17:20 master slapd[6866]: + Jul 14 23:17:20 master slapd[6866]: Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [43d817ff] Jul 14 23:17:20 master slapd[6866]: bdb_idl_delete_key: 4b04 [8d36bbfb] bzw.: Jul 14 23:35:17 master slapd[10826]: connection_get(34) Jul 14 23:35:17 master slapd[10826]: connection_get(34) Jul 14 23:35:17 master slapd[10826]: send_ldap_result: err=0 matched="" text="" Jul 14 23:35:17 master slapd[10826]: connection_get(34) Jul 14 23:35:17 master slapd[10826]: SRCH "dc=drei" 2 0 Jul 14 23:35:17 master slapd[10826]: 1 0 0 Jul 14 23:35:17 master slapd[10826]: filter: (&(objectClass=posixAccount)(uid=postfix)) Jul 14 23:35:17 master slapd[10826]: attrs: Jul 14 23:35:17 master slapd[10826]: Jul 14 23:35:17 master slapd[10826]: bdb_idl_fetch_key: [b49d1940]
Kein Blocker für MS1.
*** Bug 24738 has been marked as a duplicate of this bug. ***
*** Bug 26908 has been marked as a duplicate of this bug. ***
Auf meinem i386-Test-VM aufgetreten bei einem "udm dns/reverse_zone remove": "strace slapd" zeigt nur noch sched_yield()-Aufrufe. # gdb -p `pidof slapd` --batch -ex "set pagination 0" -ex "thread apply all backtrace" -ex detach Thread 7 (Thread 0xae8dbb70 (LWP 19244)): #0 0xb77bc416 in __kernel_vsyscall () #1 0xb72dce66 in epoll_wait () from /lib/i686/cmov/libc.so.6 #2 0x080752b3 in ?? () #3 0xb735d955 in start_thread () from /lib/i686/cmov/libpthread.so.0 #4 0xb72dc5ee in clone () from /lib/i686/cmov/libc.so.6 Thread 6 (Thread 0xae4dab70 (LWP 19245)): #0 0xb77bc416 in __kernel_vsyscall () #1 0xb72b3dec in sched_yield () from /lib/i686/cmov/libc.so.6 #2 0xb7779bc7 in ldap_pvt_thread_yield () from /usr/lib/libldap_r-2.4.so.2 #3 0xb6eb515d in bdb_cache_delete () from /usr/lib/ldap/back_bdb.so #4 0xb6ea1490 in bdb_delete () from /usr/lib/ldap/back_bdb.so #5 0x080e2d51 in overlay_op_walk () #6 0x080e37d2 in ?? () #7 0x08092d97 in fe_op_delete () #8 0x08093274 in do_delete () #9 0x08078634 in ?? () #10 0x08078ebf in ?? () #11 0xb7778e84 in ?? () from /usr/lib/libldap_r-2.4.so.2 #12 0xb735d955 in start_thread () from /lib/i686/cmov/libpthread.so.0 #13 0xb72dc5ee in clone () from /lib/i686/cmov/libc.so.6 Thread 5 (Thread 0xadfd8b70 (LWP 19258)): #0 0xb77bc416 in __kernel_vsyscall () #1 0xb7361fcf in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0 #2 0xb76155bc in __db_pthread_mutex_lock () from /usr/lib/libdb-4.8.so #3 0xb7614bf4 in __db_tas_mutex_lock () from /usr/lib/libdb-4.8.so #4 0xb76ac82f in __lock_get_internal () from /usr/lib/libdb-4.8.so #5 0xb76acc99 in __lock_get () from /usr/lib/libdb-4.8.so #6 0xb76dc0ef in __db_lget () from /usr/lib/libdb-4.8.so #7 0xb7634047 in __bam_search () from /usr/lib/libdb-4.8.so #8 0xb761f7e2 in ?? () from /usr/lib/libdb-4.8.so #9 0xb76210ba in ?? () from /usr/lib/libdb-4.8.so #10 0xb76cc90f in __dbc_iget () from /usr/lib/libdb-4.8.so #11 0xb76cd25c in __dbc_get () from /usr/lib/libdb-4.8.so #12 0xb76d6a47 in __dbc_get_pp () from /usr/lib/libdb-4.8.so #13 0xb6eaf987 in bdb_dn2id () from /usr/lib/ldap/back_bdb.so #14 0xb6eb5f3f in bdb_cache_find_ndn () from /usr/lib/ldap/back_bdb.so #15 0xb6eaf036 in bdb_dn2entry () from /usr/lib/ldap/back_bdb.so #16 0xb6ea6cc8 in bdb_search () from /usr/lib/ldap/back_bdb.so #17 0x080e2d51 in overlay_op_walk () #18 0x080e37d2 in ?? () #19 0x0807acb6 in fe_op_search () #20 0x0807b556 in do_search () #21 0x08078634 in ?? () #22 0x08078ebf in ?? () #23 0xb7778e84 in ?? () from /usr/lib/libldap_r-2.4.so.2 #24 0xb735d955 in start_thread () from /lib/i686/cmov/libpthread.so.0 #25 0xb72dc5ee in clone () from /lib/i686/cmov/libc.so.6 Thread 4 (Thread 0xacad4b70 (LWP 19408)): #0 0xb77bc416 in __kernel_vsyscall () #1 0xb7361fcf in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0 #2 0xb76155bc in __db_pthread_mutex_lock () from /usr/lib/libdb-4.8.so #3 0xb7614bf4 in __db_tas_mutex_lock () from /usr/lib/libdb-4.8.so #4 0xb76ac82f in __lock_get_internal () from /usr/lib/libdb-4.8.so #5 0xb76acc99 in __lock_get () from /usr/lib/libdb-4.8.so #6 0xb76dc0ef in __db_lget () from /usr/lib/libdb-4.8.so #7 0xb7634047 in __bam_search () from /usr/lib/libdb-4.8.so #8 0xb761f7e2 in ?? () from /usr/lib/libdb-4.8.so #9 0xb76210ba in ?? () from /usr/lib/libdb-4.8.so #10 0xb76cc90f in __dbc_iget () from /usr/lib/libdb-4.8.so #11 0xb76cd25c in __dbc_get () from /usr/lib/libdb-4.8.so #12 0xb76d6a47 in __dbc_get_pp () from /usr/lib/libdb-4.8.so #13 0xb6eaf987 in bdb_dn2id () from /usr/lib/ldap/back_bdb.so #14 0xb6eb5f3f in bdb_cache_find_ndn () from /usr/lib/ldap/back_bdb.so #15 0xb6eaf036 in bdb_dn2entry () from /usr/lib/ldap/back_bdb.so #16 0xb6ea6cc8 in bdb_search () from /usr/lib/ldap/back_bdb.so #17 0x080e2d51 in overlay_op_walk () #18 0x080e37d2 in ?? () #19 0x0807acb6 in fe_op_search () #20 0x0807b556 in do_search () #21 0x08078634 in ?? () #22 0x08078ebf in ?? () #23 0xb7778e84 in ?? () from /usr/lib/libldap_r-2.4.so.2 #24 0xb735d955 in start_thread () from /lib/i686/cmov/libpthread.so.0 #25 0xb72dc5ee in clone () from /lib/i686/cmov/libc.so.6 Thread 3 (Thread 0xac5d2b70 (LWP 19409)): #0 0xb77bc416 in __kernel_vsyscall () #1 0xb7361fcf in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0 #2 0xb76155bc in __db_pthread_mutex_lock () from /usr/lib/libdb-4.8.so #3 0xb7614bf4 in __db_tas_mutex_lock () from /usr/lib/libdb-4.8.so #4 0xb76ac82f in __lock_get_internal () from /usr/lib/libdb-4.8.so #5 0xb76acc99 in __lock_get () from /usr/lib/libdb-4.8.so #6 0xb76dc0ef in __db_lget () from /usr/lib/libdb-4.8.so #7 0xb7634047 in __bam_search () from /usr/lib/libdb-4.8.so #8 0xb761f7e2 in ?? () from /usr/lib/libdb-4.8.so #9 0xb76210ba in ?? () from /usr/lib/libdb-4.8.so #10 0xb76cc90f in __dbc_iget () from /usr/lib/libdb-4.8.so #11 0xb76cd25c in __dbc_get () from /usr/lib/libdb-4.8.so #12 0xb76d6a47 in __dbc_get_pp () from /usr/lib/libdb-4.8.so #13 0xb6eb3b71 in bdb_idl_fetch_key () from /usr/lib/ldap/back_bdb.so #14 0xb6eab831 in bdb_key_read () from /usr/lib/ldap/back_bdb.so #15 0xb6eae361 in bdb_filter_candidates () from /usr/lib/ldap/back_bdb.so #16 0xb6eaed00 in ?? () from /usr/lib/ldap/back_bdb.so #17 0xb6ead1e0 in bdb_filter_candidates () from /usr/lib/ldap/back_bdb.so #18 0xb6eaed00 in ?? () from /usr/lib/ldap/back_bdb.so #19 0xb6ead1e0 in bdb_filter_candidates () from /usr/lib/ldap/back_bdb.so #20 0xb6ea79ae in bdb_search () from /usr/lib/ldap/back_bdb.so #21 0x080e2d51 in overlay_op_walk () #22 0x080e37d2 in ?? () #23 0x0807acb6 in fe_op_search () #24 0x0807b556 in do_search () #25 0x08078634 in ?? () #26 0xb7778e84 in ?? () from /usr/lib/libldap_r-2.4.so.2 #27 0xb735d955 in start_thread () from /lib/i686/cmov/libpthread.so.0 #28 0xb72dc5ee in clone () from /lib/i686/cmov/libc.so.6 Thread 2 (Thread 0xab8cfb70 (LWP 19641)): #0 0xb77bc416 in __kernel_vsyscall () #1 0xb7361fcf in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0 #2 0xb7779ae4 in ldap_pvt_thread_cond_wait () from /usr/lib/libldap_r-2.4.so.2 #3 0xb7778ee4 in ?? () from /usr/lib/libldap_r-2.4.so.2 #4 0xb735d955 in start_thread () from /lib/i686/cmov/libpthread.so.0 #5 0xb72dc5ee in clone () from /lib/i686/cmov/libc.so.6 Thread 1 (Thread 0xb71df6c0 (LWP 19241)): #0 0xb77bc416 in __kernel_vsyscall () #1 0xb735eb45 in pthread_join () from /lib/i686/cmov/libpthread.so.0 #2 0xb7779c24 in ldap_pvt_thread_join () from /usr/lib/libldap_r-2.4.so.2 #3 0x08071ea3 in slapd_daemon () #4 0x0805e79d in main ()
Zwei Infos dazu: 1. Howard Chu antwortete auf unseren Bugreport ( http://www.openldap.org/its/index.cgi/Incoming?id=6856 ): > Try again using 2.4.24. There was a bug with back-bdb delete fixed recently > (ITS#6577) so the relevant code has changed since .23. ITS#6577: http://www.openldap.org/its/index.cgi/Software%20Bugs?selectid=6577 Wir verwenden in UCS 3.0 weiterhin OpenLDAP 2.4.23 (siehe https://forge.univention.org/bugzilla/show_bug.cgi?id=24484#c3 ). 2. Vermutlich unwahrscheinlich, dass dieser Workaround aus http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=303057 hilft, weil bei uns der Default für set_lk_max_lockers schon auf 9000 steht: > After torturing my setup with different scripts and trying to to rebuild > the normal workload, I am confident, after having run > > watch -n1 -d "db4.2_stat -c" > > for some time in parallel, the sched_yield() loop occurs, because the > bdb-backend runs out of lockers. At least this is what I get from ITS#2030 > and from various other resources (mostly documentation from Sleepycat). Anpassbar per shell# ucr set ldap/database/bdb/set_lk_max_lockers=20000 Dabei ggf. den Hinweis aus http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=303057#39 beachten: > putting a DB_CONFIG file into > the directory has no effect after the initial database was created so > I'd like to ask if you did it "in time".
This issue was fixed upstream with 2.4.32: Fixed slapd-bdb/hdb cache hang under high load (ITS#7222) See also: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=7222;selectid=7222 After applying the patch I was unable to reproduce it. So it will be automatically fixed with Bug #31697.
Will be fixed through Bug #31697. *** This bug has been marked as a duplicate of bug 31697 ***
Verified. Our upstream bug reoport (ITS #6856) has also been closed after I notified them that the problem seems to be fixed by ITS#7222.
UCS 3.2 has been released: http://docs.univention.de/release-notes-3.2-en.html http://docs.univention.de/release-notes-3.2-de.html If this error occurs again, please use "Clone This Bug".