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):
Steps to Reproduce:
1. start slapd
2. press 'reset'
3. boot computer again
Actual Results: boot process hangs on "Starting slapd"
"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.
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 ?
openldap-servers-2.3.30-2.fc6 has improved startup checks and stale locks should
not be problem anymore