kevin martin wrote:
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!
If this module was built for and working with OpenLDAP 2.4, then it needs to be modified to work with 2.5. If you compiled it against a 2.5 source tree, without any other modifications, you should have gotten a compile error.
Regards,
Kevin Martin
On Fri, Aug 27, 2021 at 11:30 AM Quanah Gibson-Mount <quanah@symas.com mailto:quanah@symas.com> wrote:
--On Friday, August 27, 2021 11:44 AM -0500 kevin martin <ktmdms@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>