[389-users] Re: Crash with SEGV after compacting

On 7/12/23 10:14, Mathieu Baudier wrote:
> 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 ?

Yes it is fixed in 389-ds-base-1.4.4.16


>
>> 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.


If you need to find a temporary workaround, I think promoting the server
to be a supplier could be a workaround. Drawback is that it will store
changes in changelog but if there not a lot of changes it has no disk
impact neither significant response time impact.


> Thanks again for your help,
>
> Mathieu
> _______________________________________________
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue