Tuesday, July 11, 2023

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


On 7/11/23 9:43 AM, Thierry Bordaz wrote:

Hello,

Unfortunately the original backtrace did not contain symbol and I can not say if the bug was already fixed

Thread 1 (Thread 0x7f7c42a4e700 (LWP 22323)):
#0 0x00007f7c54258c9c in ??? () at /usr/lib/x86_64-linux-gnu/dirsrv/plugins/libback-ldbm.so
#1 0x00007f7c5425b4c4 in ??? () at /usr/lib/x86_64-linux-gnu/dirsrv/plugins/libback-ldbm.so
#2 0x00007f7c57ac2941 in ??? () at /lib/x86_64-linux-gnu/libnspr4.so
#3 0x00007f7c57a61ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#4 0x00007f7c578caa2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

I recall some bugs were recently fixed related to compaction interval/tod but not sure they were related.

Yeah I don't recall any crashes related to DB compaction.  The recent "fixes" were for the scheduling of compaction.

But 389-ds-base-1.4.4 is not maintained anymore so it is missing A LOT of fixes (probably including some CVE's).  I strongly suggest getting to 389-ds-base-2.x sooner than later.

Mark

Could you install the debugsource and collect a new backtrace ?

regards
thierry

On 7/11/23 14:18, Mathieu Baudier wrote:
Hello,

thank you for your quick answer!

The OP of this thread has already posted a backtrace:

We use the same version as the OP (1.4.4.11) :

$ sudo apt list 389-ds-base
389-ds-base/oldstable,now 1.4.4.11-2 amd64 [installed]

which is the one provided by Debian 11 / bullseye, and which has not changed for a while.

We don't use replication on these instances.

If this backtrace is not sufficient, I am happy to reproduce the steps on a dedicated environment.

Dependening on your analysis, we will probably have to notify Debian, but I am not sure whether they will want to patch it for Debian 11.
So, maybe I will have to look at Debian 12 / bookworm (the new 'Debian stable'), and see whether the issue still occurs.

Cheers,

Mathieu

On Tue, 2023-07-11 at 11:51 +0200, Thierry Bordaz wrote:
Hi,

What version are you running ? Are you running a replicated topology,
what is the crashing server (supplier, consumer, hub) ?

Do you have a backtrace of the crash (with debugsource) ?

Unfortunately I doubt compaction can be disabled (it is part of the
checkpointing that is mandatory). It can be delayed with compaction
interval or timeof day but not suppressed.

best regards
thierry

On 7/11/23 09:51, Mathieu Baudier wrote:
Hello,

we have exactly the same problem (also on Debian 11). 389-ds crashes when compacting.

Is there a related bug ticket to track?

Is it possible / advisable to disable compacting? (our instances are critical but very small, with only credentials in them)
If yes, how can it be done?

Thanks in advance!

Mathieu
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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  
--   Directory Server Development Team

No comments:

Post a Comment