Bug 243753

Summary:	messagebus fails to start if the system is configured with ldap authentication
Product:	Red Hat Enterprise Linux 5	Reporter:	Sebastian Marten <sebi4711>
Component:	nss_ldap	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	low
Version:	5.0	CC:	amcnabb, amessina, ask, axel.thimm, bojan, dqarras, jarod, jplans, jsafrane, j, loganjerry, rbulling
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	RHBA-2007-0676	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-11-07 16:37:43 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:

Description Sebastian Marten 2007-06-11 18:20:10 UTC

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

Description of problem:
The script /etc/init.d/messagebus hangs during bootup if the system is
configured for LDAP authentication. Disabling LDAP authentication solves the
problem.

Version-Release number of selected component (if applicable):
dbus-0.61-3.fc5.1

How reproducible:
Always.

Steps to Reproduce:
1. configured LDAP server
2. authconfig and enable LDAP authentication to local LDAP server
3. reboot the system

  
Actual results:
System hangs during messagebus startup.

Expected results:
System should not hang.

Additional info:

-- Additional comment from Jerry.James on 2007-01-23 11:18 EST --
I'm seeing something similar in FC6, except that the system doesn't actually
hang.  If you let it run long enough, the messagebus eventually starts.  The
problem is that the /etc/rc.d/init.d/ldap script has priority 27 and
/etc/rc.d/init.d/messagebus has priority 22.  Therefore, when the messagebus
starts up, it repeatedly tries to contact the not-yet-running LDAP server,
continuing on only after all attempts have timed out.  Looking in
/var/log/messages shows lots of lines like this:

Jan 22 12:47:24 abbott rpc.statd[2802]: nss_ldap: reconnecting to LDAP server (s
leeping 8 seconds)...
Jan 22 12:47:25 abbott dbus-daemon: nss_ldap: reconnecting to LDAP server (sleep
ing 8 seconds)...
Jan 22 12:47:32 abbott rpc.statd[2802]: nss_ldap: reconnecting to LDAP server (s
leeping 16 seconds)...
Jan 22 12:47:33 abbott dbus-daemon: nss_ldap: reconnecting to LDAP server (sleep
ing 16 seconds)...

with the number of seconds slept doubling each time until it reaches 64.  The
script priorities need to be adjusted to fix this.

-- Additional comment from Jerry.James on 2007-01-26 11:31 EST --
I examined all scripts with priorities from 21 to 27, inclusive, and concluded
that the ldap server depends on none of them.  Therefore, I changed the priority
of /etc/rc.d/init/ldap to 21.  My system booted up quickly and with no failures.
 I recommend this change.

The version on this bug should be changed to fc6, but I can't do it.


-- Additional comment from carwyn on 2007-01-28 08:56 EST --
I can confirm that this bug persists in FC6. Dbus is still triggering lookups to
ldap and waiting for a 
timeout. My ldap.conf contains:

nss_initgroups_ignoreusers root, ldap, named, avahi, haldaemon

.. but it is still looking for something else in LDAP.

Note that bug #186527 also refers to this problem.

-- Additional comment from jwilson on 2007-02-08 09:56 EST --
My vote is to set openldap to start/stop at 21/79 instead of 27/73...

-- Additional comment from jsafrane on 2007-05-22 09:06 EST --
Please add "dbus" to "nss_initgroups_ignoreusers" in /etc/ldap.conf:

nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus

###########

I found the same bug at RHEL Version 5.

Both solutions works on my system.
It's possible to fix it? Its pretty bad to use LDAP authentication and then the
system didn't reboot or boot very slow

Comment 1 RHEL Program Management 2007-06-15 17:54:09 UTC

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 2 Nalin Dahyabhai 2007-06-29 17:31:13 UTC

I'd like to come up with a better fix (one which will avoid having to change the
nss_initgroups_ignoreusers again and again later), but absent that, I guess this
will have to do for now.

Comment 8 errata-xmlrpc 2007-11-07 16:37:43 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 the 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-2007-0676.html

Comment 9 Jose Plans 2009-02-07 13:39:11 UTC

*** Bug 484489 has been marked as a duplicate of this bug. ***

Comment 10 Andrew McNabb 2009-02-07 21:07:24 UTC

As explained in the errata, this workaround only makes the delays "less common".  I think the only real solution would be incorporating nss-ldapd.  The workaround is great, but it seems a little premature to close the bug.

Comment 11 Daniel Qarras 2009-02-07 21:44:50 UTC

> I think the only real solution would be incorporating nss-ldapd.

It seems that the chosen path is SSSD:

https://fedoraproject.org/wiki/Features/SSSD