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