Arch Linux

Hmm, I've been having the same problem too, though I thought it was because I changed my configuration. Now that I think of it, the problem did start to occur after the last udev update. A simple workaround is to put take ldap out of the hosts line in nsswitch.conf, so that it looks like this,

hosts: files dns

My best guess is that the new udev added several rules which are relying on users/groups that are not present locally in /etc/passwd and /etc/group, so it refers to the next item in nsswitch.conf, and if your nsswitch.conf looks like

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

Then nss_ldap will try to fetch the necessary entries from ldap. In the process it does a hostname resolution and hangs in an infinite loop since it can't contact the ldap server for hostname lookup. It's just a guess, but I suppose the fix would be to make sure all users/groups used by udev are present in /etc/passwd and /etc/group.

Interesting, i don't use ldap in my system, but try this in your group line in /etc/nsswitch.conf

group: files ldap[unavail=return]

The workaround proposed by Kaiting Chen solved the problem.
The configuration "hosts: dns ldap" is the default given by nsswitch.conf.ldap. Maybe we should change this to avoid this kind of problem ?

No, the workaround is incorrect because it doesn't allow resolution of hostnames from LDAP.

Hi everyone!

I have the same Problem.... Arch needs more than 180 Sek to load UDev.... The Workaround doenst work for me... What should i do?

Greetings from Germany!

Another posibility I guess is run udevd in two stages: in the first stage, load udevd in the same place but with the parameter --resolve-names=late (or maybe =never), and in the second stage load without any parameters after loading the ldap daemon and trigger again udev events, so all devices will be with the correct gids.

@Paul and Christian:
please paste your exact nsswitch.conf (without a workaround)

# Begin /etc/nsswitch.conf

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

publickey: files

hosts: files dns ldap
networks: files

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

netgroup: files

# End /etc/nsswitch.conf

I resolved the problem by setting "bind_policy soft" in nss_ldap.conf instead of "bind_policy hard".

So is this something we can actually do something about, or should we recommend changing the bind_policy as you have done?

I have just read this : http://www.liquidx.net/blog/2006/04/03/nss_ldap-undocumented-nss_reconnect_tries/

bind_policy soft seems to be a bad workaround because ldap resolution may fail on high network load.

This workaround seems to be better : adding the following to /etc/nss_ldap.conf :
nss_reconnect_tries 1
nss_reconnect_sleeptime 1
nss_reconnect_maxsleeptime 8
nss_reconnect_maxconntries 2

I have just tested it on an archbox, it boots fine with bind_policy hard, so for the moment I prefer this solution. It think it should be added to the default /etc/nss_ldap.conf file.

Now with new initscripts(2010.01) that support hooks, can use as I suggested above udevd --resolve-names=never, then in the first hook after ldap is working, can relaunch udevd to set the corrects groups.

I guess that is a good idea, not only for this but also for other purposes: udevd can have a separate startup script, then can use a conf.d/udev or something like this.

@Jan: what do you think about solution of Paul in nss_ldap? So maybe can close this old ticket.

[sorry if this arrives twice]

Are people still experiencing this problem?

@Kaiting: could you find out what users/groups are missing? I just looked through my /etc/group and /lib/udev/rules.d/, and everything looks to be the way it should.

In my opinion, this problem should be solved by filing bug reports against packages that add udev rules, but do not add the required users/groups.

There is a similar RedHat bug report (https://bugzilla.redhat.com/show_bug.cgi?id=234541), in which the udev maintainer comments:

"Kay Sievers 2007-04-02 05:41:03 EDT
Please just fix your /etc/nsswitch.conf to lookup /etc/group first. And make
sure, _all_ required system users exist in the /etc/group file.

This isn't a bug in udev nor glibc. System users which are not stored on the
local system, but used in udev-rules, are a "configuration bug", which can't be
worked around."

I suggest closing this bug.