* Jan Evert van Grootheest ([EMAIL PROTECTED]) wrote: > I've tried it. I'm not sure you have...
> During boot udevd attempts to resolve a few groups (group scanner, group > scanner, group scanner, group nvram, user tss, group tss, group fuse, > group rdma, group rdma), as far as I understand the logs. Those fail. Ok. > Udevd attempts to resolve 9 items. These are the logs of one such attempt: > INIT: version 2.86 booting [...] > udevd[882]: nss_ldap: could not search LDAP server - Server is unavailable > udevd[882]: lookup_group: error resolving group 'scanner': Illegal seek > ---------------- end of log ----------------- > > So this results in a delay of some 204 seconds per item. For a total of > about 1800 seconds, or about 30 minutes. Right, with the defaults... The idea was to reduce those. I've played with this some in preparation of 251-6. Try: reconn_maxconntries = 2 reconn_tries = 1 reconn_sleeptime = 1 reconn_maxsleeptime = 8 Or you could try the 251-6 packages I've built w/ these defaults here: http://kenobi.snowman.net/~sfrost/libnss-ldap/ This should result in 3 attempts with a 1 second sleep between the 2nd and 3rd. > I've tried changing the bind_timelimit and the timelimit in > /etc/libnss-ldap.conf. Both have no influence on the behaviour. > So either those do not apply to the tcp connection or this configuration > file does not used. Might it be that the initrd filesystem is still in use? bind_timelimit is a parameter passed to libldap actually regarding the connection and timelimit is for a max time regarding how long to wait for search results. > In nssswitch.conf I have 'files ldap' for passwd, group and shadow. So > had those been present in the files, these wouldn't have been searched > in ldap. > This means that any system using ldap might run into those delays? With the defaults from upstream, yes. There are a couple of other options- fail immediately (bind_policy soft) or reduce the timeouts (what I've suggested above). Currently we try to allow the boot to come up cleanly and then switch the bind policy over to 'hard' once we have an expectation of LDAP services being available (ie: networking and whatnot). Unfortunately that turned out to be more fragile than I expected and more people run libnss-ldap on their LDAP servers than I would have expected, which causes additional problems. Thanks, Stephen
signature.asc
Description: Digital signature
