Hi,
we are experiencing the exact same error on version 2.4.5.
[11/Jul/2025:12:05:59.340776929 +0200] - ERR -
agmt="cn=replication-agreement-ldap-consumer-1-test"
(ldap-consumer-1-test:636) - clcache_load_buffer - Can't locate CSN
6870e207000100010000 in the changelog (DB rc=-12797). If replication
stops, the consumer may need to be reinitialized.
[11/Jul/2025:12:05:59.349374401 +0200] - ERR -
agmt="cn=replication-agreement-ldap-consumer-2-test"
(ldap-consumer-2-test:636) - clcache_load_buffer - Can't locate CSN
6870e207000200010000 in the changelog (DB rc=-12797). If replication
stops, the consumer may need to be reinitialized.
I have seen the error msg "clcache_load_buffer - Can't load changelog
buffer starting at CSN ..." once, but that was when I was experimenting
with using nsds5ReplicaIgnoreMissingChange=once. But since this produced
even worse results than not having set that attribute I have reverted to
not having it set.
Unfortunately I am not able to run the dbscan command, because we are
using mdb and not bdb and "dbscan -D mdb ..." produces the error message
"Can't initialize db plugin: mdb"
As for reproducing: It seems that it happenes when a sufficiently large
volume of changes is made in a single connection. I have seen it with as
low as 40 operations per connection.
I hope this helps in debugging.
Kind regards
Julian Kippels
Am 11.07.25 um 11:47 schrieb Thierry Bordaz via 389-users:
> Hi,
>
> This is interesting finding and something we have not seen so far.
> Did you also see some logs like "lcache_load_buffer - Can't load
> changelog buffer starting at CSN...' ?
> It is logged when a replication agreement is preparing an iterator and
> can not locate the starting point (csn) in the replication changelog.
>
> Did you dump the changelog with dbscan ?
> For a given missing CSN (from logs), are you able to retrieve it with:
> dbscan -f /var/lib/dirsrv/slapd-instance/db/<backend_name>/
> replication_changelog.db -k <csn>
>
> I was not able to reproduce on 2.6.1-6. Did you identify a reproducible
> testcase ? (size of the DB, number of update, How long did it happen
> after the topology was setup...)
>
>
> best regards
> thierry
>
> On 7/11/25 8:30 AM, Fl Sch via 389-users wrote:
>> Hello,
>>
>> we have recently upgraded our 389-ds setup to version 2.6.1 running on
>> AlmaLinux 9.6 (installed from the official AlmaLinux appstream repo).
>> Or upgrade approach was to build a completely new setup, import all
>> the data and afterwards switch the IP addresses of the old and new
>> servers.
>> Our setup consists of 2 suppliers (mdir01 + mdir02) and 2 consumers
>> (sdir01 + sdir02). Both suppliers each have a replication agreement
>> between each other, aswell as agreements to both consumers. Our
>> provisioning system is designed to only write changes to mdir01, it
>> just uses mdir02 in case it can't reach mdir01.
>> Our clients (DHCP servers) use all 4 directory servers.
>>
>> Since the upgrade we have that problem that we observe the following
>> messages in the error logs of both suppliers:
>> <code>
>> [10/Jul/2025:09:58:55.479913820 +0200] - ERR - agmt="cn=agreement-
>> mdir01-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN
>> 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication
>> stops, the consumer may need to be reinitialized.
>> [10/Jul/2025:09:58:55.484629809 +0200] - ERR - agmt="cn=agreement-
>> mdir01-to-mdir02" (10:1389) - clcache_load_buffer - Can't locate CSN
>> 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication
>> stops, the consumer may need to be reinitialized.
>> [10/Jul/2025:09:58:55.484868342 +0200] - ERR - agmt="cn=agreement-
>> mdir01-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN
>> 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication
>> stops, the consumer may need to be reinitialized.
>> [10/Jul/2025:10:01:07.738009372 +0200] - ERR - agmt="cn=agreement-
>> mdir01-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN
>> 686f734300000f4b0000 in the changelog (DB rc=-12797). If replication
>> stops, the consumer may need to be reinitialized.
>> [10/Jul/2025:10:01:07.741023198 +0200] - ERR - agmt="cn=agreement-
>> mdir01-to-mdir02" (10:1389) - clcache_load_buffer - Can't locate CSN
>> 686f734300000f4b0000 in the changelog (DB rc=-12797). If replication
>> stops, the consumer may need to be reinitialized.
>>
>> [09/Jul/2025:12:18:14.429187195 +0200] - ERR - agmt="cn=agreement-
>> mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN
>> 686eb26600000f4b0000 in the changelog (DB rc=-12797). If replication
>> stops, the consumer may need to be reinitialized.
>> [09/Jul/2025:12:18:14.430628311 +0200] - ERR - agmt="cn=agreement-
>> mdir02-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN
>> 686eb26600000f4b0000 in the changelog (DB rc=-12797). If replication
>> stops, the consumer may need to be reinitialized.
>> [09/Jul/2025:12:18:16.909625172 +0200] - ERR - agmt="cn=agreement-
>> mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN
>> 686eb26800000f4b0000 in the changelog (DB rc=-12797). If replication
>> stops, the consumer may need to be reinitialized.
>> [09/Jul/2025:12:18:16.913147068 +0200] - ERR - agmt="cn=agreement-
>> mdir02-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN
>> 686eb26800000f4b0000 in the changelog (DB rc=-12797). If replication
>> stops, the consumer may need to be reinitialized.
>> [09/Jul/2025:12:42:30.255121122 +0200] - ERR - agmt="cn=agreement-
>> mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN
>> 686f60d500010f4b0000 in the changelog (DB rc=-12797). If replication
>> stops, the consumer may need to be reinitialized.
>> </code>
>>
>> On mdir01 these messages appear on average every 5 minutes during peak
>> hours.
>> On mdir02 much more infrequently, on average every 15-20 minutes.
>>
>> However, looking through the changelog I can find all the CSNs which
>> it apparently can't locate:
>> <code>
>> changetype: delete
>> replgen: 62b5bf320000010f0000
>> csn: 686f72bf00050f4b0000
>> nsuniqueid: da0de304-593411f0-aef0dc83-b57f4cfd
>> dn:
>> ClientIdentifier=00:00:00:00:d9:05,ou=dhcpldap,o=customer,dc=domain,dc=net
>>
>> changetype: delete
>> replgen: 62b5bf320000010f0000
>> csn: 686f734300000f4b0000
>> nsuniqueid: 4c315e08-5d6111f0-aef0dc83-b57f4cfd
>> dn:
>> ClientIdentifier=00:00:00:00:c6:f4,ou=dhcpldap,o=customer,dc=domain,dc=net
>>
>> changetype: delete
>> replgen: 62b5bf320000010f0000
>> csn: 686eb26600000f4b0000
>> nsuniqueid: 54f4e05b-04a311f0-9233a0e8-dc56aea6
>> dn:
>> ClientIdentifier=00:00:00:00:26:99,ou=dhcpldap,o=customer,dc=domain,dc=net
>>
>> changetype: delete
>> replgen: 62b5bf320000010f0000
>> csn: 686eb26800000f4b0000
>> nsuniqueid: 463ba84b-0af711f0-a597a0e8-dc56aea6
>> dn:
>> ClientIdentifier=00:00:00:00:f7:a0,ou=dhcpldap,o=customer,dc=domain,dc=net
>>
>> changetype: add
>> replgen: 62b5bf320000010f0000
>> csn: 686f60d500010f4b0000
>> nsuniqueid: e9d45f81-5d5811f0-aef0dc83-b57f4cfd
>> parentuniqueid: 6167af03-f3c311ec-862ceac3-35201d04
>> dn:
>> ClientIdentifier=00:00:00:00:16:68,ou=dhcpldap,o=customer,dc=domain,dc=net
>> change:: ...
>> </code>
>>
>> All the changes are populated to all directory servers in the cluster.
>> So there is no real problem visible.
>> In general, we have not seen any problems with replication whatsoever,
>> we just have these seemingly "false" messages in the error log.
>>
>> Changelog trim is currently set to the following values:
>> <code>
>> nsslapd-changelogmaxage: 30d
>> nsslapd-changelogtrim-interval: 3600
>> </code>
>>
>> Does anybody know why these error messages appear? And if / how we can
>> get rid of them?
>> I just want to make sure that there is really no underlying issue
>> somewhere. And if those messages really falsely appear, I would like
>> to get rid of them if possible to avoid confusion and to stop spamming
>> the error logs.
>>
>>
>> Thank you very much in advance.
>
Friday, July 11, 2025
[389-users] Re: Error message "Can't locate CSN in the changelog", allthough CSN is present in the changelog
Hi,
This is interesting finding and something we have not seen so far.
Did you also see some logs like "lcache_load_buffer - Can't load
changelog buffer starting at CSN...' ?
It is logged when a replication agreement is preparing an iterator and
can not locate the starting point (csn) in the replication changelog.
Did you dump the changelog with dbscan ?
For a given missing CSN (from logs), are you able to retrieve it with:
dbscan -f
/var/lib/dirsrv/slapd-instance/db/<backend_name>/replication_changelog.db
-k <csn>
I was not able to reproduce on 2.6.1-6. Did you identify a reproducible
testcase ? (size of the DB, number of update, How long did it happen
after the topology was setup...)
best regards
thierry
On 7/11/25 8:30 AM, Fl Sch via 389-users wrote:
> Hello,
>
> we have recently upgraded our 389-ds setup to version 2.6.1 running on AlmaLinux 9.6 (installed from the official AlmaLinux appstream repo). Or upgrade approach was to build a completely new setup, import all the data and afterwards switch the IP addresses of the old and new servers.
> Our setup consists of 2 suppliers (mdir01 + mdir02) and 2 consumers (sdir01 + sdir02). Both suppliers each have a replication agreement between each other, aswell as agreements to both consumers. Our provisioning system is designed to only write changes to mdir01, it just uses mdir02 in case it can't reach mdir01.
> Our clients (DHCP servers) use all 4 directory servers.
>
> Since the upgrade we have that problem that we observe the following messages in the error logs of both suppliers:
> <code>
> [10/Jul/2025:09:58:55.479913820 +0200] - ERR - agmt="cn=agreement-mdir01-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> [10/Jul/2025:09:58:55.484629809 +0200] - ERR - agmt="cn=agreement-mdir01-to-mdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> [10/Jul/2025:09:58:55.484868342 +0200] - ERR - agmt="cn=agreement-mdir01-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> [10/Jul/2025:10:01:07.738009372 +0200] - ERR - agmt="cn=agreement-mdir01-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f734300000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> [10/Jul/2025:10:01:07.741023198 +0200] - ERR - agmt="cn=agreement-mdir01-to-mdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f734300000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
>
> [09/Jul/2025:12:18:14.429187195 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26600000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> [09/Jul/2025:12:18:14.430628311 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26600000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> [09/Jul/2025:12:18:16.909625172 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26800000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> [09/Jul/2025:12:18:16.913147068 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26800000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> [09/Jul/2025:12:42:30.255121122 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686f60d500010f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> </code>
>
> On mdir01 these messages appear on average every 5 minutes during peak hours.
> On mdir02 much more infrequently, on average every 15-20 minutes.
>
> However, looking through the changelog I can find all the CSNs which it apparently can't locate:
> <code>
> changetype: delete
> replgen: 62b5bf320000010f0000
> csn: 686f72bf00050f4b0000
> nsuniqueid: da0de304-593411f0-aef0dc83-b57f4cfd
> dn: ClientIdentifier=00:00:00:00:d9:05,ou=dhcpldap,o=customer,dc=domain,dc=net
>
> changetype: delete
> replgen: 62b5bf320000010f0000
> csn: 686f734300000f4b0000
> nsuniqueid: 4c315e08-5d6111f0-aef0dc83-b57f4cfd
> dn: ClientIdentifier=00:00:00:00:c6:f4,ou=dhcpldap,o=customer,dc=domain,dc=net
>
> changetype: delete
> replgen: 62b5bf320000010f0000
> csn: 686eb26600000f4b0000
> nsuniqueid: 54f4e05b-04a311f0-9233a0e8-dc56aea6
> dn: ClientIdentifier=00:00:00:00:26:99,ou=dhcpldap,o=customer,dc=domain,dc=net
>
> changetype: delete
> replgen: 62b5bf320000010f0000
> csn: 686eb26800000f4b0000
> nsuniqueid: 463ba84b-0af711f0-a597a0e8-dc56aea6
> dn: ClientIdentifier=00:00:00:00:f7:a0,ou=dhcpldap,o=customer,dc=domain,dc=net
>
> changetype: add
> replgen: 62b5bf320000010f0000
> csn: 686f60d500010f4b0000
> nsuniqueid: e9d45f81-5d5811f0-aef0dc83-b57f4cfd
> parentuniqueid: 6167af03-f3c311ec-862ceac3-35201d04
> dn: ClientIdentifier=00:00:00:00:16:68,ou=dhcpldap,o=customer,dc=domain,dc=net
> change:: ...
> </code>
>
> All the changes are populated to all directory servers in the cluster. So there is no real problem visible.
> In general, we have not seen any problems with replication whatsoever, we just have these seemingly "false" messages in the error log.
>
> Changelog trim is currently set to the following values:
> <code>
> nsslapd-changelogmaxage: 30d
> nsslapd-changelogtrim-interval: 3600
> </code>
>
> Does anybody know why these error messages appear? And if / how we can get rid of them?
> I just want to make sure that there is really no underlying issue somewhere. And if those messages really falsely appear, I would like to get rid of them if possible to avoid confusion and to stop spamming the error logs.
>
>
> Thank you very much in advance.
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
This is interesting finding and something we have not seen so far.
Did you also see some logs like "lcache_load_buffer - Can't load
changelog buffer starting at CSN...' ?
It is logged when a replication agreement is preparing an iterator and
can not locate the starting point (csn) in the replication changelog.
Did you dump the changelog with dbscan ?
For a given missing CSN (from logs), are you able to retrieve it with:
dbscan -f
/var/lib/dirsrv/slapd-instance/db/<backend_name>/replication_changelog.db
-k <csn>
I was not able to reproduce on 2.6.1-6. Did you identify a reproducible
testcase ? (size of the DB, number of update, How long did it happen
after the topology was setup...)
best regards
thierry
On 7/11/25 8:30 AM, Fl Sch via 389-users wrote:
> Hello,
>
> we have recently upgraded our 389-ds setup to version 2.6.1 running on AlmaLinux 9.6 (installed from the official AlmaLinux appstream repo). Or upgrade approach was to build a completely new setup, import all the data and afterwards switch the IP addresses of the old and new servers.
> Our setup consists of 2 suppliers (mdir01 + mdir02) and 2 consumers (sdir01 + sdir02). Both suppliers each have a replication agreement between each other, aswell as agreements to both consumers. Our provisioning system is designed to only write changes to mdir01, it just uses mdir02 in case it can't reach mdir01.
> Our clients (DHCP servers) use all 4 directory servers.
>
> Since the upgrade we have that problem that we observe the following messages in the error logs of both suppliers:
> <code>
> [10/Jul/2025:09:58:55.479913820 +0200] - ERR - agmt="cn=agreement-mdir01-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> [10/Jul/2025:09:58:55.484629809 +0200] - ERR - agmt="cn=agreement-mdir01-to-mdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> [10/Jul/2025:09:58:55.484868342 +0200] - ERR - agmt="cn=agreement-mdir01-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> [10/Jul/2025:10:01:07.738009372 +0200] - ERR - agmt="cn=agreement-mdir01-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f734300000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> [10/Jul/2025:10:01:07.741023198 +0200] - ERR - agmt="cn=agreement-mdir01-to-mdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f734300000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
>
> [09/Jul/2025:12:18:14.429187195 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26600000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> [09/Jul/2025:12:18:14.430628311 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26600000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> [09/Jul/2025:12:18:16.909625172 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26800000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> [09/Jul/2025:12:18:16.913147068 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26800000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> [09/Jul/2025:12:42:30.255121122 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686f60d500010f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
> </code>
>
> On mdir01 these messages appear on average every 5 minutes during peak hours.
> On mdir02 much more infrequently, on average every 15-20 minutes.
>
> However, looking through the changelog I can find all the CSNs which it apparently can't locate:
> <code>
> changetype: delete
> replgen: 62b5bf320000010f0000
> csn: 686f72bf00050f4b0000
> nsuniqueid: da0de304-593411f0-aef0dc83-b57f4cfd
> dn: ClientIdentifier=00:00:00:00:d9:05,ou=dhcpldap,o=customer,dc=domain,dc=net
>
> changetype: delete
> replgen: 62b5bf320000010f0000
> csn: 686f734300000f4b0000
> nsuniqueid: 4c315e08-5d6111f0-aef0dc83-b57f4cfd
> dn: ClientIdentifier=00:00:00:00:c6:f4,ou=dhcpldap,o=customer,dc=domain,dc=net
>
> changetype: delete
> replgen: 62b5bf320000010f0000
> csn: 686eb26600000f4b0000
> nsuniqueid: 54f4e05b-04a311f0-9233a0e8-dc56aea6
> dn: ClientIdentifier=00:00:00:00:26:99,ou=dhcpldap,o=customer,dc=domain,dc=net
>
> changetype: delete
> replgen: 62b5bf320000010f0000
> csn: 686eb26800000f4b0000
> nsuniqueid: 463ba84b-0af711f0-a597a0e8-dc56aea6
> dn: ClientIdentifier=00:00:00:00:f7:a0,ou=dhcpldap,o=customer,dc=domain,dc=net
>
> changetype: add
> replgen: 62b5bf320000010f0000
> csn: 686f60d500010f4b0000
> nsuniqueid: e9d45f81-5d5811f0-aef0dc83-b57f4cfd
> parentuniqueid: 6167af03-f3c311ec-862ceac3-35201d04
> dn: ClientIdentifier=00:00:00:00:16:68,ou=dhcpldap,o=customer,dc=domain,dc=net
> change:: ...
> </code>
>
> All the changes are populated to all directory servers in the cluster. So there is no real problem visible.
> In general, we have not seen any problems with replication whatsoever, we just have these seemingly "false" messages in the error log.
>
> Changelog trim is currently set to the following values:
> <code>
> nsslapd-changelogmaxage: 30d
> nsslapd-changelogtrim-interval: 3600
> </code>
>
> Does anybody know why these error messages appear? And if / how we can get rid of them?
> I just want to make sure that there is really no underlying issue somewhere. And if those messages really falsely appear, I would like to get rid of them if possible to avoid confusion and to stop spamming the error logs.
>
>
> Thank you very much in advance.
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce]Fedora 43 Rawhide 20250711.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event
for Fedora 43 Rawhide 20250711.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan
Notable package version changes:
anaconda - 20250708.n.0: anaconda-43.28-1.fc43.src, 20250711.n.0: anaconda-43.29-1.fc43.src
kiwi - 20250708.n.0: kiwi-10.2.24-3.fc43.src, 20250711.n.0: kiwi-10.2.27-1.fc43.src
lorax - 20250708.n.0: lorax-43.5-1.fc43.src, 20250711.n.0: lorax-43.6-1.fc43.src
Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/43
You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:
https://fedoraproject.org/wiki/Test_Results:Fedora_43_Rawhide_20250711.n.0_Summary
The individual test result pages are:
https://fedoraproject.org/wiki/Test_Results:Fedora_43_Rawhide_20250711.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_43_Rawhide_20250711.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_43_Rawhide_20250711.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_43_Rawhide_20250711.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_43_Rawhide_20250711.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_43_Rawhide_20250711.n.0_Security_Lab
Thank you for testing!
--
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
--
_______________________________________________
test-announce mailing list -- test-announce@lists.fedoraproject.org
To unsubscribe send an email to test-announce-leave@lists.fedoraproject.org
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://lists.fedoraproject.org/archives/list/test-announce@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
for Fedora 43 Rawhide 20250711.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan
Notable package version changes:
anaconda - 20250708.n.0: anaconda-43.28-1.fc43.src, 20250711.n.0: anaconda-43.29-1.fc43.src
kiwi - 20250708.n.0: kiwi-10.2.24-3.fc43.src, 20250711.n.0: kiwi-10.2.27-1.fc43.src
lorax - 20250708.n.0: lorax-43.5-1.fc43.src, 20250711.n.0: lorax-43.6-1.fc43.src
Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/43
You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:
https://fedoraproject.org/wiki/Test_Results:Fedora_43_Rawhide_20250711.n.0_Summary
The individual test result pages are:
https://fedoraproject.org/wiki/Test_Results:Fedora_43_Rawhide_20250711.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_43_Rawhide_20250711.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_43_Rawhide_20250711.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_43_Rawhide_20250711.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_43_Rawhide_20250711.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_43_Rawhide_20250711.n.0_Security_Lab
Thank you for testing!
--
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
--
_______________________________________________
test-announce mailing list -- test-announce@lists.fedoraproject.org
To unsubscribe send an email to test-announce-leave@lists.fedoraproject.org
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://lists.fedoraproject.org/archives/list/test-announce@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Thursday, July 10, 2025
[389-users] Error message "Can't locate CSN in the changelog", allthough CSN is present in the changelog
Hello,
we have recently upgraded our 389-ds setup to version 2.6.1 running on AlmaLinux 9.6 (installed from the official AlmaLinux appstream repo). Or upgrade approach was to build a completely new setup, import all the data and afterwards switch the IP addresses of the old and new servers.
Our setup consists of 2 suppliers (mdir01 + mdir02) and 2 consumers (sdir01 + sdir02). Both suppliers each have a replication agreement between each other, aswell as agreements to both consumers. Our provisioning system is designed to only write changes to mdir01, it just uses mdir02 in case it can't reach mdir01.
Our clients (DHCP servers) use all 4 directory servers.
Since the upgrade we have that problem that we observe the following messages in the error logs of both suppliers:
<code>
[10/Jul/2025:09:58:55.479913820 +0200] - ERR - agmt="cn=agreement-mdir01-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[10/Jul/2025:09:58:55.484629809 +0200] - ERR - agmt="cn=agreement-mdir01-to-mdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[10/Jul/2025:09:58:55.484868342 +0200] - ERR - agmt="cn=agreement-mdir01-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[10/Jul/2025:10:01:07.738009372 +0200] - ERR - agmt="cn=agreement-mdir01-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f734300000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[10/Jul/2025:10:01:07.741023198 +0200] - ERR - agmt="cn=agreement-mdir01-to-mdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f734300000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[09/Jul/2025:12:18:14.429187195 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26600000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[09/Jul/2025:12:18:14.430628311 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26600000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[09/Jul/2025:12:18:16.909625172 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26800000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[09/Jul/2025:12:18:16.913147068 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26800000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[09/Jul/2025:12:42:30.255121122 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686f60d500010f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
</code>
On mdir01 these messages appear on average every 5 minutes during peak hours.
On mdir02 much more infrequently, on average every 15-20 minutes.
However, looking through the changelog I can find all the CSNs which it apparently can't locate:
<code>
changetype: delete
replgen: 62b5bf320000010f0000
csn: 686f72bf00050f4b0000
nsuniqueid: da0de304-593411f0-aef0dc83-b57f4cfd
dn: ClientIdentifier=00:00:00:00:d9:05,ou=dhcpldap,o=customer,dc=domain,dc=net
changetype: delete
replgen: 62b5bf320000010f0000
csn: 686f734300000f4b0000
nsuniqueid: 4c315e08-5d6111f0-aef0dc83-b57f4cfd
dn: ClientIdentifier=00:00:00:00:c6:f4,ou=dhcpldap,o=customer,dc=domain,dc=net
changetype: delete
replgen: 62b5bf320000010f0000
csn: 686eb26600000f4b0000
nsuniqueid: 54f4e05b-04a311f0-9233a0e8-dc56aea6
dn: ClientIdentifier=00:00:00:00:26:99,ou=dhcpldap,o=customer,dc=domain,dc=net
changetype: delete
replgen: 62b5bf320000010f0000
csn: 686eb26800000f4b0000
nsuniqueid: 463ba84b-0af711f0-a597a0e8-dc56aea6
dn: ClientIdentifier=00:00:00:00:f7:a0,ou=dhcpldap,o=customer,dc=domain,dc=net
changetype: add
replgen: 62b5bf320000010f0000
csn: 686f60d500010f4b0000
nsuniqueid: e9d45f81-5d5811f0-aef0dc83-b57f4cfd
parentuniqueid: 6167af03-f3c311ec-862ceac3-35201d04
dn: ClientIdentifier=00:00:00:00:16:68,ou=dhcpldap,o=customer,dc=domain,dc=net
change:: ...
</code>
All the changes are populated to all directory servers in the cluster. So there is no real problem visible.
In general, we have not seen any problems with replication whatsoever, we just have these seemingly "false" messages in the error log.
Changelog trim is currently set to the following values:
<code>
nsslapd-changelogmaxage: 30d
nsslapd-changelogtrim-interval: 3600
</code>
Does anybody know why these error messages appear? And if / how we can get rid of them?
I just want to make sure that there is really no underlying issue somewhere. And if those messages really falsely appear, I would like to get rid of them if possible to avoid confusion and to stop spamming the error logs.
Thank you very much in advance.
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
we have recently upgraded our 389-ds setup to version 2.6.1 running on AlmaLinux 9.6 (installed from the official AlmaLinux appstream repo). Or upgrade approach was to build a completely new setup, import all the data and afterwards switch the IP addresses of the old and new servers.
Our setup consists of 2 suppliers (mdir01 + mdir02) and 2 consumers (sdir01 + sdir02). Both suppliers each have a replication agreement between each other, aswell as agreements to both consumers. Our provisioning system is designed to only write changes to mdir01, it just uses mdir02 in case it can't reach mdir01.
Our clients (DHCP servers) use all 4 directory servers.
Since the upgrade we have that problem that we observe the following messages in the error logs of both suppliers:
<code>
[10/Jul/2025:09:58:55.479913820 +0200] - ERR - agmt="cn=agreement-mdir01-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[10/Jul/2025:09:58:55.484629809 +0200] - ERR - agmt="cn=agreement-mdir01-to-mdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[10/Jul/2025:09:58:55.484868342 +0200] - ERR - agmt="cn=agreement-mdir01-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[10/Jul/2025:10:01:07.738009372 +0200] - ERR - agmt="cn=agreement-mdir01-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f734300000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[10/Jul/2025:10:01:07.741023198 +0200] - ERR - agmt="cn=agreement-mdir01-to-mdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f734300000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[09/Jul/2025:12:18:14.429187195 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26600000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[09/Jul/2025:12:18:14.430628311 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26600000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[09/Jul/2025:12:18:16.909625172 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26800000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[09/Jul/2025:12:18:16.913147068 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26800000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
[09/Jul/2025:12:42:30.255121122 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686f60d500010f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized.
</code>
On mdir01 these messages appear on average every 5 minutes during peak hours.
On mdir02 much more infrequently, on average every 15-20 minutes.
However, looking through the changelog I can find all the CSNs which it apparently can't locate:
<code>
changetype: delete
replgen: 62b5bf320000010f0000
csn: 686f72bf00050f4b0000
nsuniqueid: da0de304-593411f0-aef0dc83-b57f4cfd
dn: ClientIdentifier=00:00:00:00:d9:05,ou=dhcpldap,o=customer,dc=domain,dc=net
changetype: delete
replgen: 62b5bf320000010f0000
csn: 686f734300000f4b0000
nsuniqueid: 4c315e08-5d6111f0-aef0dc83-b57f4cfd
dn: ClientIdentifier=00:00:00:00:c6:f4,ou=dhcpldap,o=customer,dc=domain,dc=net
changetype: delete
replgen: 62b5bf320000010f0000
csn: 686eb26600000f4b0000
nsuniqueid: 54f4e05b-04a311f0-9233a0e8-dc56aea6
dn: ClientIdentifier=00:00:00:00:26:99,ou=dhcpldap,o=customer,dc=domain,dc=net
changetype: delete
replgen: 62b5bf320000010f0000
csn: 686eb26800000f4b0000
nsuniqueid: 463ba84b-0af711f0-a597a0e8-dc56aea6
dn: ClientIdentifier=00:00:00:00:f7:a0,ou=dhcpldap,o=customer,dc=domain,dc=net
changetype: add
replgen: 62b5bf320000010f0000
csn: 686f60d500010f4b0000
nsuniqueid: e9d45f81-5d5811f0-aef0dc83-b57f4cfd
parentuniqueid: 6167af03-f3c311ec-862ceac3-35201d04
dn: ClientIdentifier=00:00:00:00:16:68,ou=dhcpldap,o=customer,dc=domain,dc=net
change:: ...
</code>
All the changes are populated to all directory servers in the cluster. So there is no real problem visible.
In general, we have not seen any problems with replication whatsoever, we just have these seemingly "false" messages in the error log.
Changelog trim is currently set to the following values:
<code>
nsslapd-changelogmaxage: 30d
nsslapd-changelogtrim-interval: 3600
</code>
Does anybody know why these error messages appear? And if / how we can get rid of them?
I just want to make sure that there is really no underlying issue somewhere. And if those messages really falsely appear, I would like to get rid of them if possible to avoid confusion and to stop spamming the error logs.
Thank you very much in advance.
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Wednesday, July 9, 2025
[389-users] Re: 389DS Version 3.1.3-1 on copr?
On Wed, Jul 09, 2025 at 05:07:30PM +0200, Viktor Ashirov wrote:
> There were only 2 builds that failed because of the missing sources. This
> copr does rebuilds from Fedora, so it might have some incompatibilities
> between EL <-> Fedora packaging.
> 3.1.3 was recently released and I haven't made builds everywhere yet.
OK, thank you,
Bryan
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
> There were only 2 builds that failed because of the missing sources. This
> copr does rebuilds from Fedora, so it might have some incompatibilities
> between EL <-> Fedora packaging.
> 3.1.3 was recently released and I haven't made builds everywhere yet.
OK, thank you,
Bryan
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[389-users] Re: 389DS Version 3.1.3-1 on copr?
Hi Bryan,
On Wed, Jul 9, 2025 at 3:20 PM Bryan K. Walton via 389-users <389-users@lists.fedoraproject.org> wrote:
Hi,
We are currently running 389-ds-base and cockpit-389-ds (both version
2.2.9) from the copr repo.
I've been monitoring
https://copr.fedorainfracloud.org/coprs/g/389ds/389-directory-server/packages/
and for the last few months, the builds for 3.1.3 have been failing.
There were only 2 builds that failed because of the missing sources. This copr does rebuilds from Fedora, so it might have some incompatibilities between EL <-> Fedora packaging.
3.1.3 was recently released and I haven't made builds everywhere yet.
Should we be getting our 389-ds rpms from another location?
Some time ago we started to do copr repos for each version. There is a repo specifically with 3.1.x:
It has 3.1.2, but not 3.1.3 yet.
I will do new builds soon.
Thanks,
Bryan
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Viktor
[389-users] 389DS Version 3.1.3-1 on copr?
Hi,
We are currently running 389-ds-base and cockpit-389-ds (both version
2.2.9) from the copr repo.
I've been monitoring
https://copr.fedorainfracloud.org/coprs/g/389ds/389-directory-server/packages/
and for the last few months, the builds for 3.1.3 have been failing.
Should we be getting our 389-ds rpms from another location?
Thanks,
Bryan
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
We are currently running 389-ds-base and cockpit-389-ds (both version
2.2.9) from the copr repo.
I've been monitoring
https://copr.fedorainfracloud.org/coprs/g/389ds/389-directory-server/packages/
and for the last few months, the builds for 3.1.3 have been failing.
Should we be getting our 389-ds rpms from another location?
Thanks,
Bryan
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Subscribe to:
Posts (Atom)