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 <[email protected]> wrote: > > > --On Friday, August 27, 2021 11:44 AM -0500 kevin martin <[email protected]> > > 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> >
