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.
Could you install the debugsource and collect a new backtrace ?
On 7/11/23 14:18, Mathieu Baudier wrote:
thank you for your quick answer!
The OP of this thread has already posted a backtrace:https://email@example.com/message/JOV45YZSNTY7IN72TGHBVYRFLDFCQNWN/
We use the same version as the OP (188.8.131.52) :
$ sudo apt list 389-ds-base389-ds-base/oldstable,now 184.108.40.206-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.
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.
On 7/11/23 09:51, Mathieu Baudier wrote:
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!
389-users mailing list -- firstname.lastname@example.org
To unsubscribe send an email to email@example.com
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 -- firstname.lastname@example.org To unsubscribe send an email to email@example.com 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://firstname.lastname@example.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- Directory Server Development Team