there is no apparent code changes between 389-ds-base-2.4.5-9 and 389-ds-base-2.4.5 that relate to the supplier's messages from ldap/servers/plugins/replication/repl5_connection.c :
[13/Nov/2024:15:54:37.513840430 -0600] - ERR - NSMMReplicationPlugin - perform_operation - agmt="cn=ldap-repb-test-ra" (ldap-repb-test:636): Failed to send extended operation: LDAP error 51 (Server is busy) [13/Nov/2024:15:54:37.515818173 -0600] - DEBUG - NSMMReplicationPlugin - check_flow_control_tot_init - agmt="cn=ldap-repb-test-ra" (ldap-repb-test:636) - Invalid message ids [ msgid sent: -1, rcv: 5] is it always failing in the same exact way? are there any error messages in the form of ERR - setup_ol_tls_conn - failed: unable to create new TLS context ? how many CPU cores are available on the supplier? is there 1 NUMA node configured for the LDAP service? verify what is the nsslapd-ioblocktimeout value, default 10000mS / 10sec , may be too long dsconf INSTANCE config get nsslapd-ioblocktimeout 2.1.105. nsslapd-ioblocktimeout https://docs.redhat.com/en/documentation/red_hat_directory_server/12/html/configuration_and_schema_reference/assembly_core-server-configuration-attributes_config-schema-reference-title#ref_nsslapd-ioblocktimeout_assembly_cn-config verify what is the nsslapd-idletimeout value, default 3600 sec, may be too long 2.1.102. nsslapd-idletimeout https://docs.redhat.com/en/documentation/red_hat_directory_server/12/html/configuration_and_schema_reference/assembly_core-server-configuration-attributes_config-schema-reference-title#ref_nsslapd-idletimeout_assembly_cn-config -> dsconf INSTANCE config get | grep timeout dsconf INSTANCE config replace nsslapd-idletimeout=xx dsconf INSTANCE config replace nsslapd-ioblocktimeout=xx may be try to change the nsds5ReplicaReleaseTimeout value from default 60sec to 45sec ( not under 30 seconds), for the duration of the LDAP init: 2.7.20. nsDS5ReplicaReleaseTimeout https://docs.redhat.com/en/documentation/red_hat_directory_server/12/html/configuration_and_schema_reference/assembly_core-server-configuration-attributes_config-schema-reference-title#ref_nsDS5ReplicaReleaseTimeout_assembly_cn-replica-cn-suffix_dn-cn-mapping-tree-cn-config or the parameter nsDS5ReplicaTimeout to a shorter value than the default of 120 sec, for the duration of the LDAP init: 2.8.32. nsDS5ReplicaTimeout https://docs.redhat.com/en/documentation/red_hat_directory_server/12/html/configuration_and_schema_reference/assembly_core-server-configuration-attributes_config-schema-reference-title#ref_nsDS5ReplicaTimeout_assembly_cn-replicationagreementname-cn-replica-cn-suffix_dn-cn-mapping-tree-cn-config -> ldapsearch -o ldif-wrap=no -LLLxD "cn=directory manager" -W -b "cn=mapping tree,cn=config" nsDS5ReplicaTimeout nsds5ReplicaProtocolTimeout nsDS5ReplicaReleaseTimeout ( dsconf INSTANCE replication set --help ... --repl-release-timeout REPL_RELEASE_TIMEOUT A timeout in seconds a replication supplier should send updates before it yields its replication session dsconf INSTANCE replication set --suffix SUFFIX ... ) eventually try using LMDB instead of BDB? was there any dsconf backup and restore previously done? note: there is no 389-ds 2.4.5-1 build on RHDS-11.x on RHEL-8.x or RHEL-8.x IdM, the 2.4.5.x builds are for RHDS-12.4 on RHEL-9.4 or RHEL-9.4 IdM, the 389-ds-base version 1.4.3.39-* was for RHDS-11.9 on RHEL-8.10 and RHEL-8.10 IdM, may be a typo in this comment? " A Rhel 8.10 provider 389-ds 2.4.5-1 can load our whole data base w/o error on the same consumer Rhel 9.4 389-DS 2.4.5-9 on port 636 LDAPS. I tried rhel 9.4 389-ds 2.4.5-1 (same version that worked on Rhel 8.10) " concern about the 389-ds-base versions mentioned: the interesting described scenario appears to be with 2.4.5-9 and 2.4.5-1 on RHEL-9.4, but the versions 389-ds-base-2.4.5-1 and 2.4.5-9 were for RHEL-9.4 IdM, not for a standalone LDAP server ( supported scenario are RHEL IdM or RHDS ) Cordially, Marc S. On Sat, Dec 28, 2024 at 11:21 PM Timothy Bouvet via 389-users < 389-users@lists.fedoraproject.org> wrote: > Is anyone seeing this 389-DS question? > -- > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@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 mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@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
