Ubuntu 7.10 hangs after "starting kernel log daemon" when using LDAP

Asked by Michael Zacherle on 2007-10-19


I installed Ubuntu 7.10 as an update to 7.04. Unfortunately, when configuring LDAP and then rebooting, the system hangs after "Starting kernel log daemon...". I've tested this now with a clean install just to be sure, and the problem is the same. I use LDAP version 3 and have configured it to use libnss-ldap and libpam_ldap with pam_password=crypt. It used to work with 6.10 an 7.04 without any problems...

Thanks for any help!

<email address hidden>

Question information

English Edit question
Ubuntu Edit question
No assignee Edit question
Solved by:
Last query:
Last reply:

This question was reopened

Anhur (linux-bernd-nmedien) said : #1


I have the same problem. One thing I found out is, that it seems, that hte file /etc/ldap.conf is not configured.
I found two entries there which do not seem to be correct.
host pointed to and base was dc=padl,dc=com, thought I entered values when installing libpam-ldap an co.
Setting those values compatible to my environment did not fix the problem. So I think there must be other missconfigured files ...

fejes (anthony-fejes) said : #2

I'm suffering the same issue - I believe I have my ldap.conf file correctly configured (thought it's a possibility that it's not.)

I have no idea where to go to start diagnosing this yet. I haven't yet figured out what process the kernel log daemon is running at boot.

Robert Schöftner (rmu) said : #3

I just had the same issue and it turned out that my ldap.conf was not correct. I wrongly used ldapi://some.ip.address, changing to ldap://some.ip.address solved it.

Mehdi AMINI (joker-eph) said : #4

I had the same problem when upgrading to gutsy. I solved it by changind bind_policy from hard to soft.

Michael Zacherle (zacherle) said : #5

My ldap.conf referred to ldap://... and not to ldapi://... , and changing the bind_policy didn't change anything here. Hmm. I had to disable LDAP on my computer for the moment and rely on local users only.

Best Anhur (linux-bernd-nmedien) said : #6


It works now for me. I edited some entries in /etc/ldap.conf after that anythning is good :-)

Here are all entries I set up in my configs. Hopefully it is of help for you too.
My LDAP Server is running on IP, the ldap manager is called "manager" and the domain is dc=ragnarok,dc=local

base dc=ragnarok,dc=local
uri ldap://
ldap_version 3
rootbinddn cn=manager, dc=ragnarok,dc=local
bind_policy soft
pam_password md5

BASE dc=ragnarok,dc=local
rootbinddn cn=nssldap,ou=DSA,dc=ragnarok,dc=local
nss_base_passwd dc=ragnarok,dc=local?sub
nss_base_shadow dc=ragnarok,dc=local?sub
nss_base_group ou=Groups,dc=ragnarok,dc=local?one
ssl no
pam_password md5

passwd: files ldap
group: files ldap
shadow: files ldap

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis

account sufficient pam_ldap.so
account required pam_unix.so

auth required pam_env.so
auth sufficient pam_unix.so likeauth nullok_secure
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

password required pam_cracklib.so retry=2 type=
password sufficient pam_unix.so nullok use_authtok md5 shadow
password sufficient pam_ldap.so use_authtok
password required pam_deny.so

session required pam_limits.so
session required pam_unix.so
session optional pam_ldap.so
session optional pam_foreground.so


With this settings everything works fine on my gutsy systems

Michael Zacherle (zacherle) said : #7

Hahaha, now it works. Thanks a lot!!!

What I changed in /etc/ldap.conf (I do not have a /etc/ldap/ldap.conf) was:

- added a slash at the end of the uri ldap://...
- changed host from name to IP
- added "rootbinddn cn=manager, dc=..."
- added "pam_passwd crypt"
- added ldap_version 3

I don't know which of these five things did the trick, but now it works. Great! The bind_policy soft didn't change the behaviour at all.



Michael Zacherle (zacherle) said : #8

Thanks Anhur, that solved my question.

Mehdi AMINI (joker-eph) said : #9


I don't know which of these five things did the trick, but now it works.
> Great! The bind_policy soft didn't change the behaviour at all.

It would be fine if you can try each of those parameters to identify where
was the problem.



Anhur (linux-bernd-nmedien) said : #10

Funny thing that in my system the problem was solved after adding
  bind_policy soft

Without this entry the system did not get across "starting kernel log daemon".

Tyrel Newton (tyrel-newton) said : #11

I was having the same problem and tried the five listed above in addition to setting "bind_policy soft". I'm not sure what ultimately did it, but I'm guessing it was the bind_policy since it lets a bind fail immediately rather than retrying a bunch of times.

As an aside, I noticed somewhere (I think the changelogs for sysklogd) some note about changing the user that the syslog daemons run as. Since this problem wasn't present in feisty, I'm betting they are related problems, though I don't really know how at the moment . . .

fejes (anthony-fejes) said : #12

Oddly enough, the solution for me was to do an apt-get remove libnss-ldap.

Once that was done, everything works again... very odd.

Mehdi AMINI (joker-eph) said : #13

If you remove libss-ldap, how do you access to ldap ?

Motin (motin) said : #14

I don't even use ldap but get this hang... Removing libnss-ldap doesn't help. Any ideas?