Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 156787

Summary: ldap service fails to start
Product: [Fedora] Fedora Reporter: Petr Krištof <petr>
Component: openldapAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: 2.2.23-5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-19 21:47:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 136450    
Description Flags
needed option added none

Description Petr Krištof 2005-05-04 09:32:27 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050417 Fedora/1.7.7-1.3.1

Description of problem:
ldap service failt to start everytime due bug in init script.
slaptest program is called without mandatory option "-u"

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

How reproducible:

Steps to Reproduce:
1. Install openldap, openldap-servers
2. service ldap start


Actual Results:  ]# service ldap start
Checking configuration files for :  slap_startup failed (test would succeed using the -u switch)

Expected Results:  Service should start up.

Additional info:

Comment 1 Petr Krištof 2005-05-04 09:34:42 UTC
Created attachment 113998 [details]
needed option added

This patch adds needed option "-u" to slaptest.

Comment 2 Nalin Dahyabhai 2005-05-19 21:47:22 UTC
The -u flag is not mandatory -- what "slaptest -u" does is run the test in
read-only mode, so that failures to obtain read-write locks on the directory
database doesn't signal an error.  The thing is that if your directory server
can't obtain a lock on its database, then that's a symptom of a problem which
needs human intervention.

Apparently it also errors out if you don't already have a database, which I'd
have missed due to assuming that the database is created with 'slapadd' first. 
Fixing in 2.2.23-5 and later.  Please reopen this bug ID if you find that this
doesn't solve the problem.