dbus and LDAP woes resolved

Geoff's blog

dbus and LDAP woes resolved

Tuesday, May 29. 2007

Fired up spock, my desktop PC, this morning and it didn't boot or, to be more accurate, it hung half way through the boot process - very annoying.
Being a Gentoo box I have the boot scripts running in parallel so it was impossible to see which script was causing the problem. Knoppix to the rescue! I switched the boot scripts to start in series, rebooted and got a surprise - it was dbus causing the hang - huh! No problem I entered interactive mode and skipped the script, now I could investigate the problem ... except I couldn't; every time I tried to log on spock hung again - WTF!

Back to knoppix and I decided to make the logon as simple as possible so I removed the ldap references from nsswitch.conf and bingo, I could log in.

Now kirk is my server and that's running slapd, a quick check found that kirk wasn't playing anymore so he got a hard re-boot. kirk is a Debian box so doesn't often go wrong but today it did and I still don't know why.

After kirk got a re-boot I could log in on spock but dbus was still taking ages to start up. I did the usual gentoo-ey things like re-emerging various libraries but still the only thing that would get dbus starting quickly was removing the ldap references from nsswitch.conf, as soon as they went back in dbus took at least a minute to start, holding up the whole boot process.
After some investigation I found out that when dbus runs it runs as user "messagebus" - aha - here's the answer: when dbus starts it must try to authenticate as messagebus, nsswitch tries both the local files and ldap to authenticate even though messagebus is a local user. As far as I can tell this behavior of nsswitch is not documented anywhere. dbus starts before the network interfaces are up hence the ldap server is not available. Getting dbus to start after the network interfaces are up (easy to do with Gentoo) got things back to normal but I wasn't happy with this answer as this configuration could easily be over-written by a package update.

It turns out the answer was in /etc/ldap.conf. This section at the bottom describes the behavior of nss_ldap when trying to make a connection:
# Timeout behavior
# Upstream nss_ldap hard-codes these values:
#nss_reconnect_tries 5 # number of times to double the sleep time
#nss_reconnect_sleeptime 4 # initial sleep value
#nss_reconnect_maxsleeptime 64 # max sleep value to cap at
#nss_reconnect_maxconntries 2 # how many tries before sleeping
# This leads to a delay of 124 seconds (4+8+16+32+64=124) per lookup if the
# server is not available.

# For Gentoo's distribution of nss_ldap, as of 250-r1, we use these values
# (The hardwired constants in the code are changed to them as well):
nss_reconnect_tries 4 # number of times to double the sleep time
nss_reconnect_sleeptime 1 # initial sleep value
nss_reconnect_maxsleeptime 16 # max sleep value to cap at
nss_reconnect_maxconntries 2 # how many tries before sleeping
# This leads to a delay of 15 seconds (1+2+4+8=15)

# If you are impatient, and know your LDAP server is reliable, fast or local,
# you may wish to use these values instead:
#nss_reconnect_tries 1 # number of times to double the sleep time
#nss_reconnect_sleeptime 1 # initial sleep value
#nss_reconnect_maxsleeptime 1 # max sleep value to cap at
#nss_reconnect_maxconntries 3 # how many tries before sleeping
# This leads to a delay of 1 second

I disabled the enabled reconnect options and enabled those at the bottom, this gives a delay of three seconds when the ldap server is unavailable which it always is when dbus starts, and when a parallel boot up is selected then it isn't even noticeable.
Posted by Geoffrey Clements at 19:20 | Comments (5) | Trackbacks (0)

Trackbacks
Trackback specific URI for this entry

No Trackbacks

Comments
Display comments as (Linear | Threaded)

thanks for the information.
#1 oomu on 2007-07-11 09:38 (Reply)
I'm not clear on what you disabled and enabled. Could you please clarify?

Thanks! This is driving me nuts.
#2 John Woods (Homepage) on 2008-05-15 23:38 (Reply)
Sorry for not being clear.

All the enabled comments are in the second paragraph from the listing of /etc/ldap.conf, hence, by placing a # in front of the following lines I disabled them:

nss_reconnect_tries 4 # number of times to double the sleep time
nss_reconnect_sleeptime 1 # initial sleep value
nss_reconnect_maxsleeptime 16 # max sleep value to cap at
nss_reconnect_maxconntries 2 # how many tries before sleeping

I then enabled the equivalent lines in the third paragraph , i.e. the following lines were enabled by deleting the # at the start of each line:

#nss_reconnect_tries 1 # number of times to double the sleep time
#nss_reconnect_sleeptime 1 # initial sleep value
#nss_reconnect_maxsleeptime 1 # max sleep value to cap at
#nss_reconnect_maxconntries 3 # how many tries before sleeping

I hope that helps!
#2.1 Geoffrey Clements on 2008-05-16 13:30 (Reply)
I just had one of these events myself. Another step to take is to make sure nsswitch.conf has "files ldap" and not ldap first.
#3 Michael Llaneza on 2009-02-25 01:30 (Reply)
The root cause for this problem is that dbus-daemon uses getgrouplist(2) to retrieve a list of groups for all the users in the policy files. This is nonsense: groups are not needed at this time at all, so the should not be retrieved in the first place. They can be retrieved later, when they are needed for authorization decisions. That would also take care of the fact that group memberships change as naming services become available during boot or when LDAP contents change. So someone really has to fix the logic of dbus-daemon.
#4 Andreas Mueller (Homepage) on 2010-04-21 10:45 (Reply)

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA
 
Submitted comments will be subject to moderation before being displayed.
 

Competition entry by David Cummins powered by Serendipity v1.0

Calendar

Back July '10
Sun Mon Tue Wed Thu Fri Sat
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

Blog Administration

Open login screen