Bug 118678

Summary: slapd hangs on startup when not shut down cleanly
Product: [Fedora] Fedora Reporter: Ulrich Drepper <drepper>
Component: openldapAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-19 18:55:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 114963, 123268, 136451    

Description Ulrich Drepper 2004-03-18 20:15:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b)
Gecko/20040317

Description of problem:
In some situations slapd can be shut down incorrectly and leave the
database lock files behind:

/var/lib/ldap/__db.001
/var/lib/ldap/__db.002
/var/lib/ldap/__db.003
/var/lib/ldap/__db.004
/var/lib/ldap/__db.005

When this happens, slapd hangs without any visible sign on startup,
waiting for the locking to go away.

The ldap start script should check whether these files exist and if
yes, check whether there is a running process.  if not, the fiels
should be removed.  If this is deemed to dangerous, the a message
should be issued to tell the user about the fact and ask her/him to do it.

Version-Release number of selected component (if applicable):
openldap-2.1.25-5.1

How reproducible:
Didn't try

Steps to Reproduce:
1.probably kill -9 of slapd
2.restart
3.

(alternatively, create fake __db* files

Actual Results:  hangs

Expected Results:  starts up

Additional info:

Comment 1 Nalin Dahyabhai 2005-05-19 18:55:55 UTC
Running "slaptest" first, which times out in these cases, at least prevents the
complete hang in 2.2.13-4 and later.  Versions 2.2.26-1 and later re-run with
"-u" to see if read-only access is possible, and if that succeeds, checks for a
the existence of __db.001, and if it's there, presents the warning.