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]
[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
verify what is the nsslapd-idletimeout value, default 3600 sec, may be too long
2.1.102. nsslapd-idletimeout
->
dsconf INSTANCE config get | grep timeoutdsconf 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
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
->
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
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-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
No comments:
Post a Comment