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@symas.com> wrote:

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