Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#13859 - [initscripts] Udev with LDAP blocked at "Starting Udev daemon"

Attached to Project: Arch Linux
Opened by Paul Ezvan (paulez) - Wednesday, 18 March 2009, 21:28 GMT
Last edited by Tom Gundersen (tomegun) - Sunday, 27 March 2011, 16:24 GMT
Task Type Bug Report
Category Initscripts
Status Closed
Assigned To Tobias Powalowski (tpowa)
Jan de Groot (JGC)
Aaron Griffin (phrakture)
Thomas B├Ąchler (brain0)
Tom Gundersen (tomegun)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Since last udev update, the system doesn't start and stays blocked at "Starting Udev daemon". The system uses LDAP auth with nss_ldap and PAM.
The problem occures on two different systems, I haven't rebooted the others :p
It was previously working fine without the workaround described in the wiki.
I am not sure that LDAP is the problem, but I don't know how to discover what is blocking udev daemon startup.

Additional info:
* package version(s) : udev-139-1


Steps to reproduce:
1-Configure nss to use LDAP
2-reboot
3-system is blocked during startup at step "Starting Udev daemon".
This task depends upon

Closed by  Tom Gundersen (tomegun)
Sunday, 27 March 2011, 16:24 GMT
Reason for closing:  No response
Additional comments about closing:  See my last comment.
Comment by Kaiting Chen (Phoenixfire159) - Thursday, 19 March 2009, 03:48 GMT
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.
Comment by Gerardo Exequiel Pozzi (djgera) - Thursday, 19 March 2009, 05:52 GMT
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]

Comment by Paul Ezvan (paulez) - Thursday, 19 March 2009, 16:22 GMT
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 ?
Comment by Kaiting Chen (Phoenixfire159) - Thursday, 19 March 2009, 23:19 GMT
No, the workaround is incorrect because it doesn't allow resolution of hostnames from LDAP.
Comment by Christian (TripHH) - Thursday, 16 April 2009, 15:25 GMT
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!
Comment by Gerardo Exequiel Pozzi (djgera) - Tuesday, 28 July 2009, 05:46 GMT
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.
Comment by Roman Kyrylych (Romashka) - Friday, 25 September 2009, 07:49 GMT
@Paul and Christian:
please paste your exact nsswitch.conf (without a workaround)
Comment by Paul Ezvan (paulez) - Friday, 25 September 2009, 08:24 GMT
# 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".
Comment by Aaron Griffin (phrakture) - Friday, 25 September 2009, 17:19 GMT
So is this something we can actually do something about, or should we recommend changing the bind_policy as you have done?
Comment by Paul Ezvan (paulez) - Friday, 25 September 2009, 18:20 GMT
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.
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 29 January 2010, 21:51 GMT
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.

Comment by Gerardo Exequiel Pozzi (djgera) - Monday, 06 September 2010, 04:04 GMT
@Jan: what do you think about solution of Paul in nss_ldap? So maybe can close this old ticket.
Comment by Tom Gundersen (tomegun) - Thursday, 09 December 2010, 19:35 GMT
[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.

Loading...