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:95I 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-base389-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
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
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