This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 118678 - slapd hangs on startup when not shut down cleanly
slapd hangs on startup when not shut down cleanly
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks: FC2Target FC3Target FC4Target
  Show dependency treegraph
 
Reported: 2004-03-18 15:15 EST by Ulrich Drepper
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-19 14:55:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ulrich Drepper 2004-03-18 15:15:26 EST
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 14:55:55 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.