+++ 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
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. configured LDAP server
2. authconfig and enable LDAP authentication to local LDAP server
3. reboot the system
System hangs during messagebus startup.
System should not hang.
-- Additional comment from Jerry.James@usu.edu 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: 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: 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@usu.edu 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 email@example.com 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 firstname.lastname@example.org 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 email@example.com on 2007-05-22 09:06 EST --
Please add "dbus" to "nss_initgroups_ignoreusers" in /etc/ldap.conf:
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
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
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.
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.
*** Bug 484489 has been marked as a duplicate of this bug. ***
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.
> I think the only real solution would be incorporating nss-ldapd.
It seems that the chosen path is SSSD: