thank you for your quick answer!
The OP of this thread has already posted a backtrace:
We use the same version as the OP (188.8.131.52) :
$ sudo apt list 389-ds-base
389-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 thecheckpointing that is mandatory). It can be delayed with compactioninterval or timeof day but not suppressed.best regardsthierryOn 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 -- firstname.lastname@example.orgTo unsubscribe send an email to email@example.comFedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesDo not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue