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

> 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. I have enabled replicati

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

> I will raise the issue with Debian and see whether they would be willing to > update the > package in Debian 11 / bullseye. For cross-link, here is the related Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040905 ___ 389-users

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

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 whethe

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

Hello, please find a fresh backtrace below. Is it more usable? I can also send it directly to you per email, if more practical. GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later

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

tion 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 ex

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

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