Hm, I'm not getting a segfault. I have two databases on the server: dc=example,dc=com and dc=example,dc=org. Both have syncprov, and my slave is syncrepling from both using gssapi.
I created a replicator principal, added an ACL to allow it to read everything in both trees. I didn't use k5start in the slave, since this is just a test. I kinit'ed the replicator user, chowned the credentials cache file to openldap and set KRB5CCNAME in /etc/default/slapd. Upon starting the slave, I get two connections from it logged on the master and their respective searches for each tree (see http://pastebin.ubuntu.com/25171586/ for full log and better formatting): Jul 25 18:48:23 xenial-slapd-segfault-1688575 slapd[4697]: conn=2229 fd=13 ACCEPT from IP=10.0.100.149:60168 (IP=0.0.0.0:389) Jul 25 18:48:23 xenial-slapd-segfault-1688575 slapd[4697]: conn=2230 fd=20 ACCEPT from IP=10.0.100.149:60170 (IP=0.0.0.0:389) (...) Jul 25 18:48:23 xenial-slapd-segfault-1688575 slapd[4697]: conn=2230 op=2 BIND authcid="Replicator" authzid="Replicator" Jul 25 18:48:23 xenial-slapd-segfault-1688575 slapd[4697]: conn=2230 op=2 BIND dn="uid=replicator,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=56 ssf=56 Jul 25 18:48:23 xenial-slapd-segfault-1688575 slapd[4697]: conn=2230 op=2 RESULT tag=97 err=0 text= Jul 25 18:48:23 xenial-slapd-segfault-1688575 slapd[4697]: conn=2230 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" (...) Jul 25 18:48:23 xenial-slapd-segfault-1688575 slapd[4697]: conn=2229 op=2 BIND authcid="Replicator" authzid="Replicator" Jul 25 18:48:23 xenial-slapd-segfault-1688575 slapd[4697]: conn=2229 op=2 BIND dn="uid=replicator,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=56 ssf=56 Jul 25 18:48:23 xenial-slapd-segfault-1688575 slapd[4697]: conn=2229 op=2 RESULT tag=97 err=0 text= Jul 25 18:48:23 xenial-slapd-segfault-1688575 slapd[4697]: conn=2229 op=3 SRCH base="dc=example,dc=org" scope=2 deref=0 filter="(objectClass=*)" Jul 25 18:48:23 xenial-slapd-segfault-1688575 slapd[4697]: conn=2229 op=3 SRCH attr=* + I tried multiple restarts on the slave, also between master updates with a script that creates 100 users in each tree, but no segfault. Could you share your syncrepl and syncprov settings perhaps for both databases? On the master I have just for each db: olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 And on the slave I have: olcSyncrepl: {0}rid=0 provider=ldap://xenial-slapd-segfault-1688575.lxd bind method=sasl saslmech=GSSAPI searchbase="dc=example,dc=com" schemachecking= off type=refreshAndPersist retry="60 +" and olcSyncrepl: {0}rid=1 provider=ldap://xenial-slapd-segfault-1688575.lxd bind method=sasl saslmech=GSSAPI searchbase="dc=example,dc=org" schemachecking= off type=refreshAndPersist retry="60 +" I understand it might not be an immediate segfault, or 100% cpu usage, but given the bug description I thought it was more or less constant. But maybe I'm missing something. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1688575 Title: Segmentation fault on a slave slapd (sync replication with kerberos authentication) Status in openldap: Fix Committed Status in openldap package in Ubuntu: In Progress Bug description: I have a slapd problem on a freshly installed 16.04 machine: slapd[17107]: segfault at 1a ip 00007f3c12c79f55 sp 00007f3c03c2d080 error 4 in libsasl2.so.2.0.25[7f3c12c72000+19000] I'm using the server as Slave LDAP-Server and sync replication with kerberos authentication. The service either starts and runs successfully or it fails with segmentation fault or 100% CPU. Maybe an useful info, I'm replicating two databases. When I deactivate syncrepl for one of them (doesn't matter which one) the problem is not occuring. Linux xxx 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux slapd 2.4.42+dfsg-2ubuntu3.1 libsasl2-2:amd64 2.1.26.dfsg1-14build1 libsasl2-modules:amd64 2.1.26.dfsg1-14build1 libsasl2-modules-gssapi-mit:amd64 2.1.26.dfsg1-14build1 GDB debug: Starting program: /usr/sbin/slapd -h "ldap:/// ldaps:/// ldapi:///" -u openldap -g openldap -f /etc/ldap/slapd.conf -d 256 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 590c82ab @(#) $OpenLDAP: slapd (Ubuntu) (May 11 2016 16:12:05) $ buildd@lgw01-10:/build/openldap-mF7Kfq/openldap-2.4.42+dfsg/debian/build/servers/slapd 590c82ab slapd starting [New Thread 0x7f2e96b7b700 (LWP 42139)] [New Thread 0x7f2e9637a700 (LWP 42140)] [New Thread 0x7f2e95b79700 (LWP 42141)] [New Thread 0x7f2e95378700 (LWP 42142)] [New Thread 0x7f2e94b77700 (LWP 42143)] 590c82ba slap_client_connect: URI=ldap://xxx ldap_sasl_interactive_bind_s failed (-6) 590c82ba do_syncrepl: rid=132 rc -6 retrying (9 retries left) Thread 4 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f2e95b79700 (LWP 42141)] 0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (gdb) thr apply all bt Thread 6 (Thread 0x7f2e94b77700 (LWP 42143)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e94b77700) at pthread_create.c:333 #3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 5 (Thread 0x7f2e95378700 (LWP 42142)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95378700) at pthread_create.c:333 #3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 4 (Thread 0x7f2e95b79700 (LWP 42141)): #0 0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2 #1 0x00007f2ea530f250 in ?? () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2 #2 0x00007f2ea5303d69 in sasl_client_init () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2 #3 0x00007f2ea594da6c in ldap_int_sasl_init () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #4 0x00007f2ea594db2c in ldap_int_sasl_open () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #5 0x00007f2ea594e2d4 in ldap_int_sasl_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #6 0x00007f2ea5951828 in ldap_sasl_interactive_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #7 0x00007f2ea5951a4e in ldap_sasl_interactive_bind_s () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #8 0x0000561fbc556db4 in slap_client_connect (ldp=0x561fbe1e9f68, sb=0x561fbe1e9d40) at ../../../../servers/slapd/config.c:2063 #9 0x0000561fbc5c699d in do_syncrep1 (si=0x561fbe1e9d10, op=0x7f2e95b787b0) at ../../../../servers/slapd/syncrepl.c:618 #10 do_syncrepl (ctx=<optimized out>, arg=0x561fbe1e5620) at ../../../../servers/slapd/syncrepl.c:1548 #11 0x00007f2ea59463a2 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #12 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95b79700) at pthread_create.c:333 #13 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 3 (Thread 0x7f2e9637a700 (LWP 42140)): ---Type <return> to continue, or q <return> to quit--- #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e9637a700) at pthread_create.c:333 #3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 2 (Thread 0x7f2e96b7b700 (LWP 42139)): #0 0x00007f2ea45b2e23 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84 #1 0x0000561fbc55a8f0 in slapd_daemon_task (ptr=<optimized out>) at ../../../../servers/slapd/daemon.c:2539 #2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e96b7b700) at pthread_create.c:333 #3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1 (Thread 0x7f2ea5d96740 (LWP 42138)): #0 0x00007f2ea487d98d in pthread_join (threadid=139838073845504, thread_return=0x0) at pthread_join.c:90 #1 0x0000561fbc55cc81 in slapd_daemon () at ../../../../servers/slapd/daemon.c:2932 #2 0x0000561fbc543bea in main (argc=11, argv=<optimized out>) at ../../../../servers/slapd/main.c:1017 (gdb) To manage notifications about this bug go to: https://bugs.launchpad.net/openldap/+bug/1688575/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
