Wednesday, August 3, 2022

[389-users] Crash with SEGV after compacting


My organisation is using a replicated 389-dirsrv. Lately, it has been crashing
each time after compacting.

It is replicable on our instances by lowering the compactdb-interval to
trigger the compacting:

dsconf -D "cn=Directory Manager" ldap:// -w 'PASSWORD_HERE' backend config set --compactdb-interval 300

This is the log:

[03/Aug/2022:16:06:38.552781605 +0200] - NOTICE - checkpoint_threadmain - Compacting DB start: userRoot
[03/Aug/2022:16:06:38.752592692 +0200] - NOTICE - bdb_db_compact_one_db - compactdb: compact userRoot - 8 pages freed
[03/Aug/2022:16:06:44.172233009 +0200] - NOTICE - bdb_db_compact_one_db - compactdb: compact userRoot - 888 pages freed
[03/Aug/2022:16:06:44.179315345 +0200] - NOTICE - checkpoint_threadmain - Compacting DB start: changelog
[03/Aug/2022:16:13:18.020881527 +0200] - NOTICE - bdb_db_compact_one_db - compactdb: compact changelog - 458 pages freed
dirsrv@auth-alpha.service: Main process exited, code=killed, status=11/SEGV
dirsrv@auth-alpha.service: Failed with result 'signal'.
dirsrv@auth-alpha.service: Consumed 2d 6h 22min 1.122s CPU time.

The first steps are done very quickly, but the step before the 458 pages of the
retro-changelog are freed, takes several minutes. In this time the dirsrv writes
more than 10 G and reads more than 7 G (according to iotop).

After this line is printed the dirsrv crashes within seconds.
What I also noticed is, that even though it said it freed a lot of pages the
retro-changelog does not seem to change in size.
The file `/var/lib/dirsrv/slapd-auth-alpha/db/changelog/id2entry.db` is 7.2 G
before and after the compacting.

Debian 11.4
389-ds-base/stable,now amd64

Does someone have an idea how to debug / fix this?

389-users mailing list --
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines:
List Archives:
Do not reply to spam, report it:

No comments:

Post a Comment