On Sat, Jul 11, 2026 at 4:27 PM Quanah Gibson-Mount quanah@fast-mail.org wrote:

--On Thursday, July 9, 2026 4:38 PM -0700 Ben Poliakoff benp@reed.edu wrote:

...

The syncrepl process seems to get hung up "every so often" (might run for several days without issue). Today I found that it had gotten "stuck" again (newer change to an entry on slapd-a that wasn't being propagated to slap-b and slapd-c). Sometimes in these cases, simply restarting slapd on the non-primary instances gets things moving again. Today, though, that didn't work, and I was only able to get replication moving again, by deleting the entry (on the primary slapd instance) that was being referenced in the logs, and then recreating it (also on the primary slapd instance).

Hi Ben,

I'm curious if rather than deleting/adding the entry, if you modify an attribute on the entry back to its same value if that fixes it. That's worked for me in the past.

like:

dn: uid=blah,dc... changetype: modify replace: description description: account for blah

Thanks Quanah... Just to make certain I'm understanding you correctly, given a scenario where an entry on the "primary" server has been updated, but the changes have not been replicated to the two "non-primaries", you're suggesting I try updating the entry on the "primary" server again to see if that gets the replication flow working again? I can certainly try that, the next time this issue comes up (seems to happen every few days).

By the way, when I follow the method (described previously) where I delete and recreate a "stuck" entry on the primary server, I also end up having to restart the slapd process on the two non-primary servers (ie simply deleting and recreating the entry on the primary server doesn't clear up the issue, but deleting and recreating the entry on the primary server, followed by restarting slapd on the non-primary servers tends to work, which makes it feel like a thread is "stuck" on the non-primary servers).

Ben