Description of problem: If unsing multiple databases (trees) within openldap and multiple replication, only one slurpd is started not taking care of multiple configured replogfiles. Version-Release number of selected component (if applicable): FC3 init script (the problem should be the same for more recent versions like FC5) How reproducible: Steps to Reproduce: 1. Create two databases in /etc/openldap/slapd.conf 2. Create for each a replication entry with its own replogfile 3. restart /etc/init.d/ldap 4. modify both databases (ldapadd, ...) Actual results: The second database of slapd.conf never gets successfully replicated as there is only one slurpd running Expected results: As many slurpds should be started as databases are to be replicated Additional info: This patch takes care if there is more than one replog entry and counts and starts an appropriate slurpd 71c71,81 < daemon ${slurpd} $OPTIONS $SLURPD_OPTIONS --- > i=1; > for replogfile in `grep "^replogfile" /etc/openldap/slapd.conf` > do > if "$replogfile" != "replogfile" > then > daemon ${slurpd} -r $replogfile -n $i > i=$[i+1] > fi > done
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Checked FC5: for the reported part the init script is still the same and only respecting the first occurence of 'replogfile': if [ $RETVAL -eq 0 ]; then if grep -q "^replogfile" /etc/openldap/slapd.conf; then prog=`basename ${slurpd}` echo -n $"Starting $prog: " daemon ${slurpd} $OPTIONS $SLURPD_OPTIONS RETVAL=$? echo fi fi
Also still the same startup for FC6
We had the same issue with all the Fedora Core and we used a similar update in the ldap init script (as described by the ticket submitter). Could you update the init script to add the automatic start of the required slurp based on the replogfile entries ? That would save us to patch the file on a bunch of production LDAP servers.
Fixed in openldap-2.3.34-3.fc8