Bug 613966

Summary:	Init script is working wrong if database recovery is needed
Product:	Red Hat Enterprise Linux 6	Reporter:	Jan Zeleny <jzeleny>
Component:	openldap	Assignee:	Jan Vcelak <jvcelak>
Status:	CLOSED ERRATA	QA Contact:	Ondrej Moriš <omoris>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.1	CC:	jplans, jvcelak, olaf, omoris, rvokal, tsmetana
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	openldap-2.4.23-5.el6	Doc Type:	Bug Fix
Doc Text:	- OpenLDAP server is terminated uncleanly (e.g. force power off) - slapd configuration test in initscript will fail or stuck in an infinite loop and the server will not start - removed database check from configration test in the initscript - slapd server will start, because it can recover independently from unclean termination	Story Points:	---
Clone Of:	604092	Environment:
Last Closed:	2011-05-19 13:59:32 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:	604092, 667768
Bug Blocks:

Description Jan Zeleny 2010-07-13 11:44:27 UTC

+++ This bug was initially created as a clone of Bug #604092 +++

Description of problem:
The problem is in init script (/etc/rc.d/init.d/ldap)

If recovery is required for bdb backend databases (because of unclean shutdown or other reason), the script prevents automatic recovery on start.

On start (in configtest procedure) it tries to execute "slaptest". If it fails, it won't continue.
If it fails because a bdb recovery is needed, then it is not possible to start slapd from initscipts. The automatic recovery is not performed because "slaptest" implies read-only mode.

The output looks like:

"[root@daisy ldap]# service ldap start
Checking configuration files for slapd:  bdb_db_open: unclean shutdown detected; attempting recovery.
bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered."

When slapd is then run from command line then it performs automatic recovery and works fine. It is possible then to start slapd from initscripts.

It hit me really hard - the ldap has user and group database and the nss_ldap has very long timeouts, so to be able to get the machine working after crash I had to go in single user mode and fix it by hand.

Version-Release number of selected component (if applicable):
openldap-2.3.43-12.el5


How reproducible:
Always

Steps to Reproduce:
1. Corrupt the openldap bdb files in such fashion that recovery is required and automatic recovery will be able to handle this (it may be tricky :)
2. Try to start openldap: service ldap start
3.
  
Actual results:
The slapd doesn't start, as the initscript fails in earlier stage (at slaptest)

Expected results:
The slapd is started and performs automatic recovery. I think that the "configtest" part of this script should report errors but it shouldn't do an exit in case of failure. The script should try to start the slapd anyway.

Additional info:

--- Additional comment from jzeleny on 2010-07-13 13:43:15 CEST ---

Actually just calling slaptest with -u every time will do the trick. But this is a change of behavior which is not likely to be expected in RHEL-5. It is a good idea to fix it in RHEL-6 though.

Comment 3 Jan Vcelak 2011-01-13 20:41:53 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
- OpenLDAP server is terminated uncleanly (e.g. force power off)
- slapd configuration test in initscript will fail or stuck in an infinite loop and the server will not start
- removed database check from configration test in the initscript
- slapd server will start, because it can recover independently from unclean termination

Comment 6 errata-xmlrpc 2011-05-19 13:59:32 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0673.html