slow startup after upgrade

Wed Feb 25 20:28:00 GMT 2015

John Hein wrote at 11:15 -0700 on Feb 25, 2015:
 > Corinna Vinschen wrote at 09:56 +0100 on Feb 25, 2015:
 > > On Feb 24 16:03, John Hein wrote:
 > > > Corinna Vinschen wrote at 22:13 +0100 on Feb 24, 2015:
 > > > > Hi Roger,
 > > > >
 > > > > On Feb 24 19:55, Roger Orr wrote:
 > > > > > Hello Corinna,
 > > > > > It seems slightly faster than the previous patch and I've not noticed a
 > > > > > downside yet.
 > > > > >
 > > > > >
 > > > > > CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35s(0.286/5/3) 20150220 15:47:55 i686
 > > > > > Cygwin:
 > > > > >
 > > > > > ~37ms to run echo.exe from Windows command prompt
 > > > > > ~60ms to run .\id.exe -a from Windows command prompt
 > > > > >
 > > > > > CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35s(0.286/5/3) 20150223 21:02:38 i686
 > > > > > Cygwin:
 > > > > >
 > > > > > ~35ms to run echo.exe from Windows command prompt
 > > > > > ~53ms to run .\id.exe -a from Windows command prompt
 > > > >
 > > > > That's a nice result.
 > > > >
 > > > > However, I don't quite understand this result for the older DLL.
 > > > > Weren't you reporting >4 secs as startup time from 1.7.35?!?
 > > > >
 > > > > On another note:
 > > > >
 > > > > I just uploaded a new developer snapshot (2015年02月24日). This snapshot
 > > > > should improve mkpasswd/mkgroup or, generally speaking, enumerating AD
 > > > > accounts, a lot. Can you give it a try?
 > > > >
 > > > > While you're at it, does the new snapshot still stop after 3.5K accounts
 > > > > even though you think there are 8K accounts? If so, I'd be interested
 > > > > to investigate this further. The reason is, while testing my today's
 > > > > performance improvements, I stumbled over a bug in my code which also
 > > > > resulted in enumerating less accounts as desired. So I'm not entirely
 > > > > sure your problem isn't related to a bug either.
 > > >
 > > > That mkpasswd symptom was reported by me
 > >
 > > Really? This is the first time I see your email address on this ML, and
 > > there's no name connected to it, so I don't even know if you're usually
 > > writing under another email address. At least a forename would be nice...
 >
 >
 > Bah... sorry, you should get the name in this response.
 >
 >
 > > > (well, maybe others, too).
 > > > I'm running it again, but it's still very slow, AFAICS.
 > >
 > > It shouldn't. It performs only one LDAP call now per 100 accounts,
 > > If that's still slow in your environment, I don't see any way to
 > > speed this up any further.
 > >
 > > > I'll report
 > > > how long it took when / if it finishes.
 > > >
 > > > New issue with recent snaps:
 > > >
 > > > Running the 20150224 (and *23) snapshot produces the following on Win
 > > > XP (yes, I know) if cygserver is running:
 > >
 > > Sidenote: I'm contemplating to stop supporting XP end of this year.
 >
 > I'm thinking it's either related to XP or _something_ with the
 > particular XP box I'm using (when logged in on the domain, I can't
 > disable many group policy things or temporarily inhibit AV, so it's
 > harder to find/eliminate something to pin blame on - certainly may not
 > be something the latest cygwin is doing when running on XP in a
 > "large" AD domain).
 >
 > I went to a win 7 box and the 2/24 snap makes mkpasswd -d run in 33
 > seconds and enumerates all 8016 entries. 37 seconds with the 2/25
 > snap.
 >
 > And win 7 doesn't get the 'wrong arg.type' error with the same 2/24
 > cygwin1.dll for whatever reason.
 >
 >
 > > > $ /usr/sbin/syslog-ng -F
 > > > 1 [main] syslog-ng 5776 C:\cygwin\usr\sbin\syslog-ng.exe: *** fatal error - Fetching account info from cygserver with wrong arg.type 2
 > >
 > > Try the snapshot I just uploaded (2015年02月25日). I forgot a tiny, but
 > > crucial statement in the code when I changed that code two days ago.
 > > That should be fixed now.
 > >
 > > > tcsh still taking a long time here (also XP - 3+ minutes with
 > > > cygserver running). bash & dash much quicker.
 > >
 > > Works very quickly for me. Problem is, I don't know anything about
 > > your environment. Are you working remote or in an office? How many
 > > groups are in your user token? What is the result of this funny
 > > little statement Dennis created:
 > >
 > > cmd /v:on /c "echo !TIME! & C:\cygwin64\bin\mintty.exe /bin/echo "test" & echo !TIME!"
 >
 > On win7: that command takes .17, .44, .48, .53 sec between 1st & 2nd time stamp
 >
 > That had 'db' only for passwd/group in nsswitch.conf, no cygwin procs
 > running including cygserver.
 >
 >
 > On problematic winxp box:
 > [passwd, group, db_shell: 'files db', 'files db' & /bin/dash]
 > 16.83, 17.03, 24.80, 28.79, 27.99, 27.39 sec
 >
 > [passwd, group, db_shell: db, db & /bin/dash]
 > 23.51, 27.91, 28.78 sec
 >
 > Any trials using /bin/tcsh without disabling complete.tcsh take "a
 > really long time" (TM)... from minutes with 2/25 snap to 10s of
 > minutes with 1.7.34. I mentioned this in another thread (and
 > strace sometimes showed 5 minute gaps around forks).
One further test with the 'cmd ... mintty.exe' command.
I started cygserver on the 'problematic winxp' box.
Then immediately ran the mintty.exe test after starting
the cygserver service - it took .08 sec - then .15 and .14.
Would be interesting if there are other people who could report on
experiences using 1.7.34 and later on XP boxes in an AD environment.
--
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