Re: OpenLDAP 2.5.7 dies

I'll try that.  I have narrowed it down to the ppm.so from slapd-modules/ppm.  I removed ppm.so from /usr/local/libexec/openldap, restarted slapd, ran the command that killed it prior and it didn't die, stopped slapd, recompiled ppm and installed the new ppm.so in libexec/openldap, restarted slapd and reran the password change and boom, down went Frazier!

--- Regards, Kevin Martin On Fri, Aug 27, 2021 at 11:30 AM Quanah Gibson-Mount <quanah(a)symas.com <mailto:quanah@symas.com>> wrote: --On Friday, August 27, 2021 11:44 AM -0500 kevin martin <ktmdms(a)gmail.com <mailto:ktmdms@gmail.com>> wrote: > > > 41720 sendto(3, "<165>Aug 27 15:36:40 slapd[41718]: ppm: entry > uid=kmart,ou=people,dc=lecpq,dc=com", 87, MSG_NOSIGNAL, NULL, 0) = 87 > 41720 getpid()                          = 41718 > 41720 sendto(3, "<165>Aug 27 15:36:40 slapd[41718]: ppm: Reading > pwdCheckModuleArg attribute", 75, MSG_NOSIGNAL, NULL, 0) = 75 > 41720 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} --- > 41718 <... futex resumed>)              = ? > 41720 +++ killed by SIGSEGV +++ > 41719 <... epoll_wait resumed> <unfinished ...>) = ? > 41719 +++ killed by SIGSEGV +++ > 41718 +++ killed by SIGSEGV +++ > > > > > still now coredump file.  I'll try changing the kernel.core_pattern and > see if we get something somewhere. Coredumps are often useless because they lose key information.  You want to get a trace under gdb while the process is executing. Start slapd gdb /path/to/slapd PID (gdb) cont execute the command that crashes slapd at the gdb prompt: gdb thr apply all bt full --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>