On Feb 19 17:29, John Hein wrote: > Corinna Vinschen wrote at 11:59 +0100 on Feb 18, 2015: > > Hi Cygwin friends and users, > > > > I released another very early TEST version of the next upcoming Cygwin > > release. The version number is 1.7.35-0.3. > > > > This release introduces a revision of the LDAP calls done to fetch > > information from the DC. By limiting the search scope, the calls should > > now be faster even in bigger environments. Please give it a try with > > activated "db" settings for passwd and group entries in /etc/nsswitch.conf > > > > passwd: db > > group: db > > > > Please report back your experience, especially if you're suffering > > from "slow startup" problems. > > Without 'files' in /etc/nsswitch.conf or 'cygserver' running, the > testing cycle here is slow. So I've been a bit delayed at reporting > back. I know some people have alleged wonderful speedups with > 1.7.35-0.3, but I can't report the same. > > Here I'm in an AD environment with ~8000 entries in AD (as determined > by 'mkpasswd -d | wc') and I'm in 200+ groups. I guess I'd call it > somewhat large, and the network is geographically spread out and > connected by links that vary in speed (the slowest is probably 10s of > Mbps), although there is a local AD "slave" on the local LAN. > > It's particularly slow if I force using my shell of choice (tcsh) > rather than forcing '/bin/dash' as the 'db_shell' entry in > nsswitch.conf. This is likely because of all the various things that > get executed at shell startup (csh.cshrc, profile.d/*.csh).
Just as Achim reported in https://cygwin.com/ml/cygwin/2015-02/msg00608.html You may read my reply in https://cygwin.com/ml/cygwin/2015-02/msg00610.html It would be nice to keep this stuff together in a single thread. I'm willing to work on this stuff, but I need patient testers :} > Also mkpasswd -d seems to be taking a long time (haven't had it > complete in hours now). That didn't happen with 1.7.34 - maybe > there's a local issue here on our network. In theory, the mkpasswd call should be the same as before. The LDAP call performed to enumerate the domain hasn't changed, unless... I made a single change in the filter expression for the user search: Before filter = "(&(objectClass=User)" "(objectCategory=Person)" "(userAccountControl:" LDAP_MATCHING_RULE_BIT_AND ":=512)" "(objectSid=*))"; After: filter = "(&(objectCategory=Person)" "(objectClass=User)" "(userAccountControl:" LDAP_MATCHING_RULE_BIT_AND ":=512)" "(objectSid=*))"; So I just changed the order of the objectClass and objectCategory test. If that's really the culprit, you can easily test it: Revert to the Cygwin 1.7.34-6 DLL, run `time mkpasswd -d >/dev/null' Revert to the Cygwin 1.7.35-0.3 DLL, run `time mkpasswd -d >/dev/null' Revert to the Cygwin 1.7.34-6 DLL, run `time mkpasswd -d >/dev/null' Revert to the Cygwin 1.7.35-0.3 DLL, run `time mkpasswd -d >/dev/null' Does that clearly show that 1.7.34-6 is faster performing the enumeration? If so, and despite my total puzzlement, the order in the expression seem to have an effect. > What's a good way to debug > what's happening with mkpasswd? Seems like its not doing anything. Well, it works for me. And since mkpasswd basically calls into the Cygwin DLL to enumerate, it's not mkpasswd as such, but the Cygwin DLL which is the culprit. But, if you want to be sure mkpasswd is doing "something", just don't redirect its output to a file, so the output goes to your terminal. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpNy6NMr90iS.pgp
Description: PGP signature