Comment 2 for bug 1926265

Thanks for your support.

> - Your full openldap configuration (please remove any confidential bits, of course).
There is lots of ldif files with many private datas. Do you need a particular configuration ?

> - Any log messages from slapd or related services.
olcLogLevel is "sync stats". During the last 40 minutes before (forced) kill, slapd send no more logs to syslog. You can see below an extract but it doesn't help:

Apr 27 04:50:01 front01 slapd[1023]: conn=10282468 fd=732 TLS established tls_ssf=128 ssf=128
Apr 27 04:50:01 front01 slapd[1023]: conn=10282453 op=13 SRCH base="cn=Write,cn=Waiters,cn=Monitor" scope=0 deref=2 filter="(objectClass=*)"
Apr 27 04:50:01 front01 slapd[1023]: conn=10282453 op=13 SRCH attr=monitorCounter
Apr 27 05:31:59 front01 slapd[1023]: daemon: shutdown requested and initiated.
Apr 27 05:31:59 front01 slapd[1023]: conn=10281700 fd=16 closed (slapd shutdown)
[...777 more ..... ]
Apr 27 05:31:59 front01 slapd[1023]: conn=10276270 fd=854 closed (slapd shutdown)
Apr 27 05:31:59 front01 slapd[1023]: daemon: shutdown requested and initiated.
Apr 27 05:32:18 front01 slapd[122011]: @(#) $OpenLDAP: slapd (Ubuntu) (Feb 18 2021 14:22:42) $#012#011Debian OpenLDAP Maintainers <email address hidden>
Apr 27 05:32:18 front01 slapd[122012]: bdb_db_open: database "dc=fti,dc=net": unclean shutdown detected; attempting recovery.
Apr 27 05:32:26 front01 slapd[122012]: slapd starting

>- If you can, please install the debug symbols for openldap/slapd and run "gdb -p
> $PROCESS_PID" (where "$PROCESS_PID" is slapd's PID), then run a "bt" command and attach
> the output to this bug.
Ok I install the debugging package "slapd-dbgsym" to provide a backtrace next time.

>- More information about what is going on in the system when the problem happens. For
> example, I've read that this might happen when the system load is high; do you notice that
> as well?
The servers hosting slapd are constantly under load, but issue occur even when overall CPU usage is about 5% ..
Maybe it can help you: the problem didn't occur on old Trusty machines (same config, same load).