Description of problem: A customer has configured the replication changelog DB compaction to happen at a specific time ( nsslapd-changelogcompactdb-time: 02:00 ). Nonetheless the compaction is happening much later after the scheduled time. Version-Release number of selected component (if applicable): $ head -1 errors 389-Directory/1.4.3.29 B2022.087.1507 $ 389-ds-base-libs-1.4.3.29-3.module+el8dsrv+14615+a86efbbf.x86_64 389-ds-base-1.4.3.29-3.module+el8dsrv+14615+a86efbbf.x86_64 How reproducible: At a customer site. Steps to Reproduce: 1. Configure the compaction time: # dsconf -D "cn=Directory Manager" ldaps://<HOST>:<PORT> replication set-changelog --compact-time 02:00 2. The compaction interval is set to 2 days ( nsslapd-changelogcompactdb-interval: 172800 ) 3. Check the compaction times in the errors log: $ grep "compacting replication changelogs" errors* | tail -4 errors.20220923-000111:[23/Sep/2022:03:07:19.412873289 +0200] - NOTICE - NSMMReplicationPlugin - changelog program - cl5CompactDBs - compacting replication changelogs... errors.20220923-000111:[23/Sep/2022:03:07:19.967053493 +0200] - NOTICE - NSMMReplicationPlugin - changelog program - cl5CompactDBs - compacting replication changelogs finished. errors.20220925-000136:[25/Sep/2022:08:18:24.326787653 +0200] - NOTICE - NSMMReplicationPlugin - changelog program - cl5CompactDBs - compacting replication changelogs... errors.20220925-000136:[25/Sep/2022:08:18:24.531876733 +0200] - NOTICE - NSMMReplicationPlugin - changelog program - cl5CompactDBs - compacting replication changelogs finished. $ Actual results: Compaction is happening at unplanned times. Expected results: Compaction should happen at scheduled times. Some customers cannot afford to have the DB compaction starting during peak times. Additional info:
The compaction starts at the expected time when the nsslapd-changelogcompactdb-time is unset ( thus using the default value of 23:59 ): grep -i compa /var/log/dirsrv/slapd-localhost/errors* /var/log/dirsrv/slapd-localhost/errors.20221002-000222:[02/Oct/2022:23:59:27.161439332 +0200] - NOTICE - NSMMReplicationPlugin - changelog program - cl5CompactDBs - compacting replication changelogs... /var/log/dirsrv/slapd-localhost/errors.20221002-000222:[02/Oct/2022:23:59:32.867428009 +0200] - NOTICE - NSMMReplicationPlugin - changelog program - cl5CompactDBs - compacting replication changelogs finished. /var/log/dirsrv/slapd-localhost/errors.20221004-000154:[04/Oct/2022:23:59:01.988719414 +0200] - NOTICE - NSMMReplicationPlugin - changelog program - cl5CompactDBs - compacting replication changelogs... /var/log/dirsrv/slapd-localhost/errors.20221004-000154:[04/Oct/2022:23:59:22.602587530 +0200] - NOTICE - NSMMReplicationPlugin - changelog program - cl5CompactDBs - compacting replication changelogs finished. /var/log/dirsrv/slapd-localhost/errors.20221006-000152:[06/Oct/2022:23:59:25.458998883 +0200] - NOTICE - NSMMReplicationPlugin - changelog program - cl5CompactDBs - compacting replication changelogs... /var/log/dirsrv/slapd-localhost/errors.20221006-000152:[06/Oct/2022:23:59:25.870496531 +0200] - NOTICE - NSMMReplicationPlugin - changelog program - cl5CompactDBs - compacting replication changelogs finished.
I think I know what is going on. The issue is the compaction interval. It's set to 2 days, but the way it works is that it's two days (48 hours) from the time the server "starts". It's just a timer. So if the server was restarted at 8:00, then the trim/compact thread is not going to wake up until 8:00 two days later. It wakes up, and sees that it's past the 2:00 TOD setting and thinks it must compact. The reason why 11:59 works is because it's at the very end of the day. When the time is early in the day then this can break. Continuing investigation...
Fixed upstream: https://github.com/389ds/389-ds-base/issues/5532
Hi Mark! Could you please review the DocText field with the RN text draft. Thanks, Evgenia
(In reply to Evgenia Martynyuk from comment #22) > Hi Mark! > > Could you please review the DocText field with the RN text draft. > > Thanks, > Evgenia Looks good
RN passed a peer review, RN text is release pending
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (redhat-ds:11 bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:3267