http://bugs.skolelinux.no/show_bug.cgi?id=642
------- Additional Comments From [EMAIL PROTECTED] 2004-03-19 02:00 ------- some additional information: the verbose (loglevel 1) and the shorter (loglevel 256) log are highly bloated by additional lookups due to a "top" process doing lookups and the relevant login process is hard to find. http://www.netsys.com/nssldap/2001/02/msg00085.html "There is a compatibility mode for initgroups() lookups which would result in the entire group database being iterated over, but that shouldn't be being used. You should see a query like: (&(objectClass=posixGroup)(|(memberUid=sxw)(uniqueMember=uid=sxw,ou=...)))" this is what we see in the 256 log: filter="(&(objectClass=posixGroup)(|(memberUid=finnarne) (uniqueMember=uid=finnarne,ou=People,dc=skole,dc=skolelinux,dc=no))). we must conclude that the initgroup problem as described in the thread is sloved, since the proper query is beeing used. the compatibility mode`s query "(objectClass=posixGroup)" as such is not seen. This is also supported by the fact that the initgroup patch went into libnss-ldap in version 145, long before woody release version 186 http://packages.debian.org/stable/net/libnss-ldap The slowness is therefore not to be attributed to a slow search algorithm of libnss-ldap in the ldap database. Closer inspection of the 256'er log reveals that the login bind is connection 25, and that all search queries executed within that connection both query details about finnarne and also return their results *right away*. the libnss-ldap process asks those details with one long 2 second delay inbetween. as far as slapd is concerned the login process is handled within those 2 seconds. The likely suspect for the delay is therefore not slapd but libnss-ldap or an other process higher up in the caller chain. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
