This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: TEST RELEASE: Cygwin 1.7.35-0.3


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]