Hello,
Many thanks for the quick analysis!
The crash is already fixed in 1.4.4 with
https://github.com/389ds/389-ds-base/issues/4778
The fix was about scheduling of compaction but revisit this part of code
and actually fixed this crash.
I will raise the issue with Debian and see whether they would be willing to update the
package in Debian 11 / bullseye.
(
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029040 is indirectly related, which
means that the OP and us are not the only ones affected)
My understanding is that updating 389-ds-base to v1.4.4.19 (the latest tag I could find on
github,
https://github.com/389ds/389-ds-base/tree/389-ds-base-1.4.4.19) would contain this
fix, right ?
I fully agree with Mark suggestion to move to 2.x as this branch is
not
maintained except for few fixes like this one.
Yes, definitely. Debian 12 / bookworm is providing v2.3.1 and has recently become the new
Debian stable. But upgrading obviously impacts other packages and we are still on RHEL 8
(and therefore 389-ds v1.4.3.*) for the IPA servers. While we have already successfully
tested Debian 12 + RHEL 9 with our application, it did raise some unrelated issues with
the IPA client (which are now solved in Debian 12 and on their way to RHEL 8 and 9).
So, we still have to live with the current setup for a few months, and if we don't get
this fixed in Debian 11, I am thinking of what kind of workaround we could put in place,
and I would be grateful for a quick feedback from your side :
- Is it reasonable to configure a very long delay for the compacting?
- Or should we rather rather restart dirsrv periodically in order to reset the next
delay?
I appreciate that neither is ideal, but this are small instances which can be down from
time to time (typically at night) and a restart of the LDAP server is transparent for the
application, as long as no one is trying to log in while it is down.
Thanks again for your help,
Mathieu