Andrey Repin wrote at 05:55 +0300 on Feb 20, 2015: > Greetings, John Hein! > > > 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). > > I can't comment on this matter, but this seems RATHER suspicious. > > > Just to avoid any possible cruft from my old cygwin install, I > > installed a minimal fresh cygwin. The only change was to > > nsswitch.conf: > > > passwd: db > > group: db > > db_shell: /bin/dash > > > Starting mintty with db_shell set to /bin/tcsh has taken up to a half > > hour before the prompt appears. I don't have a complicated .cshrc > > (just a few alias definitions & 'set' commands). > > You can get a more reliable test of the changes to Cygwin > specifically, if you just run `id` directly (let's say, from native > console, or a batch file).
I did something like that, but something I would not have expected to be affected by ldap issues. I ran '.\date' from cmd.exe while just 'db' was in nsswitch.conf entries. It was taking 20-35 seconds to run. That was while mkpasswd was running and maybe some other cygwin processes. After I killed mkpasswd and all other cygwin procs and tried the experiment later, it ran quickly. I thought about reporting this, but decided not to because of the uncontrolled nature of the experiment. Treating it like a UFO for now (not sure what I saw). > > 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. > > mkpasswd is trying to pull up ALL records for ALL users in the domain. > Even with recent changes, I can imagine it taking a lot of time in a spread > out network. Understood. And it could be totally affected by network activity as well. It seems a bit longer than I expected. By the way, it took 5+ hours yesterday with 1.7.35-0.3 and only got 1800 entries of the 8000. Could be some other reason than cygwin certainly. There's quite a few variables involved here. Reverting to 1.7.33 got all 8000 in about 50 minutes. But that was later in the day. > > What's a good way to debug > > what's happening with mkpasswd? Seems like its not doing anything. > > Sysinternals ADInsight, as has been mentioned before. > https://technet.microsoft.com/en-us/sysinternals/bb897539 Thanks. I'll take a look. For now I ran strace and got some possibly good info. See reply to Corinna. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
