This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: TEST RELEASE: Cygwin 1.7.35-0.3
- From: "John Hein" <3fbmqnhaz4 at snkmail dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 20 Feb 2015 13:47:47 -0700
- Subject: Re: TEST RELEASE: Cygwin 1.7.35-0.3
- Authentication-results: sourceware.org; auth=none
- References: <343520570 dot 20150220055550 at yandex dot ru>
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