X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:content-type
	:content-transfer-encoding:message-id:date:from:to:subject
	:in-reply-to:references; q=dns; s=default; b=vxjfuJjSEJqQsNtYraJ
	WgEEzw5RmKdhosl7kAZa//oEPsC5fj5nsFklc3DtvaeemauG4Og9tptJ0rai3HcZ
	ju2v+oBObwaP2TtAtlMtDVtPZL2A2nwETcbLAqssMPEHYOC7OJk6Xn34BkDPXnLi
	GdCWZkuO4Go771EJqVcM8sZQ=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:content-type
	:content-transfer-encoding:message-id:date:from:to:subject
	:in-reply-to:references; s=default; bh=YXkuWYKHV1k+mjwn+gU4puXB9
	hA=; b=beqMpNmxXgWriZ4DTyKiLYzu+orb4QUZ/rq533nq4ZjawXetobg+bMeqh
	NQ0/evm1p4L2zcsUDN0P/OZsiIrA3Rc48ISLObCh4Ey45BfRoYYXNNUVqWg8IUN/
	P3IrLfV8kV5PPkkdogOnFFfW3nr2ZPAk1GA4mYZ+34T3beBkDQ=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=1.0 required=5.0 tests=AWL,BAYES_50,HK_RANDOM_ENVFROM,HK_RANDOM_FROM,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2
X-HELO:	sneak2.sneakemail.com
MIME-Version:	1.0
Message-ID:	<6747-1424465269-214742@sneakemail.com>
Date:	Fri, 20 Feb 2015 13:47:47 -0700
From:	"John Hein" <3fbmqnhaz4 AT snkmail DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: TEST RELEASE: Cygwin 1.7.35-0.3
In-Reply-To:	<343520570.20150220055550@yandex.ru>
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

- Raw text -