Bug 156787 - ldap service fails to start
ldap service fails to start
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks: FC4Blocker
  Show dependency treegraph
 
Reported: 2005-05-04 05:32 EDT by Petr Krištof
Modified: 2007-11-30 17:11 EST (History)
0 users

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


Attachments (Terms of Use)
needed option added (348 bytes, patch)
2005-05-04 05:34 EDT, Petr Krištof
no flags Details | Diff

  None (edit)
Description Petr Krištof 2005-05-04 05:32:27 EDT
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):
openldap-servers-2.2.23-4

How reproducible:
Always

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)
                                                           [FAILED]


Expected Results:  Service should start up.

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

This patch adds needed option "-u" to slaptest.
Comment 2 Nalin Dahyabhai 2005-05-19 17:47:22 EDT
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.

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