This indicates the issue is in the BDB?* if the virtual machine has only one CPU. Adding a second CPU increases the number of transferred entries before the initialization gets stuck. So it may me some thread/transaction contention or deadlock.* if the replication agreement uses SSL(port 636) or TLS(port389). Using port 389 with LDAP protocol instead of TLS/SSL increases the number of transferred entries before the initialization gets stuck. Sometimes the initialization even ends successfully in this case.* decreasing nsslapd-db-checkpoint-interval (say, to 5 seconds) also gets the problem worseDon't know. My hypotheses are :* using plugin transactions compared to 1.2.10.x* bdb version? but even with compat-db-47 and 1.2.10 the problem still happens on CentOS7, though much less frequently. It never happens with 1.2.10 with rpm bdb on CentOS5.* change from mozilla ldap libraries to openldap libraries?seems to be some sort of thread or transaction contention that is reduced when i add CPUs/increase checkpoint interval. It really looks like the master server just does not send entries any more at some moment... SSL/TLS slows the things down so less entries are sent before everything gets stuck...I'll get back with more information (stacktraces) tomorrrow.
Another version :
insufficient entropy generation speed for TLS/SSL total update (/dev/urandom vs blocking /dev/random), especially in VMs??
insufficient entropy generation speed for TLS/SSL total update (/dev/urandom vs blocking /dev/random), especially in VMs??
-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
