From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.2 (like Gecko) Description of problem: After power failure there is a high probability that ldap startup script would hang or would fail but report success. To make it start again one has to either recreate databases or run db_recover -h /var/lib/ldap, THEN run slaptest as user ldap. Version-Release number of selected component (if applicable): openldap-servers-2.2.23-5 How reproducible: Sometimes Steps to Reproduce: 1. start slapd 2. press 'reset' 3. boot computer again Actual Results: boot process hangs on "Starting slapd" or . "Starting slapd [ OK ]", but slapd is not running. Expected Results: At very least, init script should not block booting, and report failure if slapd fails to start. Maybe good thing is to run db_recovery each time slapd starts. Additional info: When one manually runs db_recover $PATH_TO_LDAP_DB, then /sbin/service ldap start, in $PATH_TO_LDAP_DB files __db.* will be created with root permissions, and slapd would still not run. Cause is slaptest in init script.
*** Bug 171271 has been marked as a duplicate of this bug. ***
Running slaptest as user ldap is not a solution, because it does not create __db* files. These files with root permissions are created by slapd. The problem persists also in openldap-servers-2.2.9-1.FC4.
Sorry. The problem is really in slaptest. I tried slaptest -u which did not create the files, but without -u it did.
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.
openldap-servers-2.3.30-2.fc6 has improved startup checks and stale locks should not be problem anymore