RE: Compiling gcc trunk under cygwin
FYI Fixes for both issues now released to gcc trunk. Roger. -Original Message- From: Roger Orr [mailto:rog...@howzatt.demon.co.uk] Sent: 27 January 2016 00:16 To: 'cygwin@cygwin.com' Subject: RE: Compiling gcc trunk under cygwin FYI (1) Revision 232071 problem The pr66655 has a new proposed patch, which does appear to build on cygwin, and is awaiting final approval. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655 (2) Revision 232454 problem I've now reported the revision 232454 problem as pr69506 (as it's been well over a week since the problematic check-in) See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506 Regards, Roger. -Original Message- From: Roger Orr [mailto:rog...@howzatt.demon.co.uk] Sent: 23 January 2016 14:19 To: cygwin@cygwin.com Subject: Re: Compiling gcc trunk under cygwin David Wohlferd LimeGreenSocks.com> writes: > Until recently, I've been able to build gcc under cygwin just fine. But > (relatively) recent checkins (232454 & 232071) are causing problems. Have you reported the problems with 232454 to gcc yet? I've already reported the 232071 problem, on the original bug report this was trying to fix. See gcc's bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655 Roger. -- 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
RE: Compiling gcc trunk under cygwin
FYI (1) Revision 232071 problem The pr66655 has a new proposed patch, which does appear to build on cygwin, and is awaiting final approval. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655 (2) Revision 232454 problem I've now reported the revision 232454 problem as pr69506 (as it's been well over a week since the problematic check-in) See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506 Regards, Roger. -Original Message- From: Roger Orr [mailto:rog...@howzatt.demon.co.uk] Sent: 23 January 2016 14:19 To: cygwin@cygwin.com Subject: Re: Compiling gcc trunk under cygwin David Wohlferd LimeGreenSocks.com> writes: > Until recently, I've been able to build gcc under cygwin just fine. But > (relatively) recent checkins (232454 & 232071) are causing problems. Have you reported the problems with 232454 to gcc yet? I've already reported the 232071 problem, on the original bug report this was trying to fix. See gcc's bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655 Roger. -- 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
Re: Compiling gcc trunk under cygwin
David Wohlferd LimeGreenSocks.com> writes: > Until recently, I've been able to build gcc under cygwin just fine. But > (relatively) recent checkins (232454 & 232071) are causing problems. Have you reported the problems with 232454 to gcc yet? I've already reported the 232071 problem, on the original bug report this was trying to fix. See gcc's bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655 Roger. -- 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
RE: slow startup after upgrade
Good work -- at least in my environment ;-) 20150225 DLL: mkgroup 0.63s mkpasswd 0.289s compared to 20150220 DLL: mkgroup 45.8s mkpasswd: 4572.7s Output is mkgroup: 53kb, 681 lines mkpasswd: 132kb, 1081 lines. And the output *is* the same :-) Roger. -Original Message- From: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com] Sent: 25 February 2015 12:52 To: cygwin@cygwin.com Subject: Re: slow startup after upgrade On Feb 25 12:29, Achim Gratz wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: While you're at it, does the new snapshot still stop after 3.5K accounts even though you think there are 8K accounts? $ mkpasswd -d | wc I get ~30k AD accounts back in 75s instead of 315s and the network traffic is only half of the former value as well comparing the 20150224 vs. the latest 20150223 snapshot. Cool! Thanks for your feedback. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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
RE: slow startup after upgrade
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 nsswitch.conf: passwd and group both set to 'db' Regards, Roger. -Original Message- From: Roger Orr [mailto:rog...@howzatt.demon.co.uk] Sent: 23 February 2015 23:33 To: 'cygwin@cygwin.com' Subject: RE: slow startup after upgrade Hi Corinna, sounds good. I'll give this a go, all being well, tomorrow. In other news it appears that the ADInsightDll uses some shared data to communicate, so in order to get ADInsight to work with injection one has to ensure that the DLL injected is the same actual *file* as the one loaded by the ADInsight program (in the (windows) %TEMP% directory) - a copy of the DLL doesn't seem to be effective. Regards, Roger. -Original Message- From: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com] Sent: 23 February 2015 21:16 To: cygwin@cygwin.com Cc: Roger Orr Subject: Re: slow startup after upgrade Hi Roger, On Feb 16 20:02, Roger Orr wrote: Corinna Vinschen wrote: So I'd think the best way forward is to update to the 1.7.35-0.1 test release and report further from there. Thanks, this does help a little. However I will still be using the 'files' setting. Here are some results in case they're of interest. (Windows 7/64 with cygwin/64.) 1) Running cygwin echo.exe from a cmd.exe command shell a) With passwd: files and group: files in /etc/nsswitch.conf 0.03 - 0.4 s b) With 1.7.34 and default /etc/nsswitch.conf around 120s C) With 1.7.35 and default /etc/nsswitch.conf 4.4 - 4.6s I rewrote the function responsible for the slow startup, the one fetching all the group information for the groups in your user token. As I just wrote in my mail to Dennis Hagarty, the performance improvement should be noticable, even with /etc/nsswitch.conf only using the db setting for groups. The group info for a user token with 150 groups was fetched in ~50 ms rather than the ~300ms of the former code. Can you test this again with the Cygwin DLL from the latest developer snaphshot at https://cygwin.com/snapshots/ please? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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
RE: slow startup after upgrade
Corinna Vinschen wrote: 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?!? The slow (4s) startup was from an early 1.7.35 DLL before that of 20150220. From an earlier message (2015-02-17): 1) Running cygwin echo.exe from a cmd.exe command shell a) With passwd: files and group: files in /etc/nsswitch.conf 0.03 - 0.4 s b) With 1.7.34 and default /etc/nsswitch.conf around 120s C) With 1.7.35 and default /etc/nsswitch.conf 4.4 - 4.6s 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. I'll try to find time to give this a go too. Thanks, 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
RE: slow startup after upgrade
Hi Corinna, sounds good. I'll give this a go, all being well, tomorrow. In other news it appears that the ADInsightDll uses some shared data to communicate, so in order to get ADInsight to work with injection one has to ensure that the DLL injected is the same actual *file* as the one loaded by the ADInsight program (in the (windows) %TEMP% directory) - a copy of the DLL doesn't seem to be effective. Regards, Roger. -Original Message- From: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com] Sent: 23 February 2015 21:16 To: cygwin@cygwin.com Cc: Roger Orr Subject: Re: slow startup after upgrade Hi Roger, On Feb 16 20:02, Roger Orr wrote: Corinna Vinschen wrote: So I'd think the best way forward is to update to the 1.7.35-0.1 test release and report further from there. Thanks, this does help a little. However I will still be using the 'files' setting. Here are some results in case they're of interest. (Windows 7/64 with cygwin/64.) 1) Running cygwin echo.exe from a cmd.exe command shell a) With passwd: files and group: files in /etc/nsswitch.conf 0.03 - 0.4 s b) With 1.7.34 and default /etc/nsswitch.conf around 120s C) With 1.7.35 and default /etc/nsswitch.conf 4.4 - 4.6s I rewrote the function responsible for the slow startup, the one fetching all the group information for the groups in your user token. As I just wrote in my mail to Dennis Hagarty, the performance improvement should be noticable, even with /etc/nsswitch.conf only using the db setting for groups. The group info for a user token with 150 groups was fetched in ~50 ms rather than the ~300ms of the former code. Can you test this again with the Cygwin DLL from the latest developer snaphshot at https://cygwin.com/snapshots/ please? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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
RE: Very slow Cygwin startup on Windows 7
Sysinternals ADInsight is a 32bit only tool and, in order to work on
a 64bit Windows you seem to have to manually inject the DLL
ADInsightDll.dll (which is extracted into %TEMP%) into the target
(32-bit!) process.
So, it seems ADInsight seems a non-starter - for my skill level anyway.
In case it helps you, or another reader of the list, here is a simple
program that injects a named dll into a target process.
Example of using it to examine the ldap calls for cygwin's echo.exe:
- Compile as a 32-bit program using *32bit* cygwin (as ADInsight is a 32bit
process): g++ inject.cpp -o inject.exe
- Start ADInsight from SysInternals
- Start Windows command shell
- Invoke: inject.exe %TEMP%\ADInsightDll.dll c:\cygwin\bin\echo.exe hello
Regards,
Roger.
- inject.cpp -
/*
NAME
Inject.cpp
DESCRIPTION
Inject a DLL into another process
COPYRIGHT
Copyright (C) 2002,2015 by Roger Orr rog...@howzatt.demon.co.uk
This software is distributed in the hope that it will be useful, but
without WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Permission is granted to anyone to make or distribute verbatim
copies of this software provided that the copyright notice and
this permission notice are preserved, and that the distributor
grants the recipient permission for further distribution as permitted
by this notice.
Comments and suggestions are always welcome.
Please report bugs to rog...@howzatt.demon.co.uk.
EXAMPLE
Inject MyDll fred.exe
*/
#include windows.h
#include string
#include iostream
//
// Local functions
int CreateProcessHelper(char ** it, char ** end, HANDLE hProcess,
HANDLE hThread);
int InjectDLL(std::string const dllName, HANDLE hProcess);
//
int main(int argc, char **argv)
{
if (argc 3)
{
std::cerr Syntax: inject dllname progname std::endl;
return 1;
}
std::string const dllName = argv[1];
std::string const progName = argv[2];
HANDLE hProcess = 0;
HANDLE hThread = 0;
if (CreateProcessHelper(argv+2, argv+argc, hProcess, hThread) != 0)
{
return 1;
}
if (InjectDLL(dllName, hProcess) != 0)
{
TerminateProcess(hProcess, GetLastError());
return 1;
}
// resume the created process once we've loaded the DLL
if (::ResumeThread(hThread) == (DWORD)-1)
{
std::cout ResumeThread failed with GetLastError()
std::endl;
return 1;
}
DWORD ret = ::WaitForSingleObject(hProcess, INFINITE);
if (ret == WAIT_OBJECT_0)
{
DWORD exitCode;
if (GetExitCodeProcess(hProcess, exitCode))
{
std::cout Process progName terminated:
return code: exitCode std::endl;
ret = exitCode;
}
else
{
ret = GetLastError();
std::cout Process terminated: return code unavailable:
ret std::endl;
}
}
else if (ret == WAIT_FAILED)
{
std::cout Process wait failed: GetLastError() std::endl;
}
else
{
std::cout Process wait failed: ret std::endl;
}
return ret;
}
//
// Inject DLL 'dllName' into process 'hProcess'
int InjectDLL(std::string const dllName, HANDLE hProcess)
{
LPTHREAD_START_ROUTINE lpStartAddress = 0;
// Create memory in target process
LPVOID const chDllName = VirtualAllocEx(hProcess, 0, dllName.size() + 1,
MEM_COMMIT, PAGE_READWRITE);
if (chDllName == 0)
{
std::cerr VirtualAllocEx failed: GetLastError()
std::endl;
return 1;
}
// Map into my process
if (! WriteProcessMemory(hProcess, chDllName,
dllName.c_str(), dllName.size()+1, 0))
{
std::cerr WriteProcessMemory failed: GetLastError()
std::endl;
return 1;
}
lpStartAddress = (LPTHREAD_START_ROUTINE)LoadLibrary;
// Start a remote thread, at LoadLibraryA in the target process
// Note we assume KERNEL32 has a fixed load address
DWORD threadId(0);
HANDLE const hRemoteThread = CreateRemoteThread(hProcess, 0, 0,
lpStartAddress, chDllName, 0, threadId);
if (hRemoteThread == 0)
{
std::cerr CreateRemoteThread failed: GetLastError()
std::endl;
return 1;
}
WaitForSingleObject(hRemoteThread, 1);
DWORD exitCode;
if (! GetExitCodeThread(hRemoteThread, exitCode))
{
std::cerr GetExitCodeThread failed: GetLastError()
std::endl;
return 1;
}
if (exitCode == STILL_ACTIVE)
{
std::cout Remote thread still running... std::endl;
return 1
RE: slow startup after upgrade
I've tested again with the first patched cygwin1.dll: CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35(0.286/5/3) 2015-02-16 13:18 i686 Cygwin I can confirm the connections are occurring within the ldap_search_s call - here is one of the call stacks: 00ebc31c 76e5c451 0278 0045dd28 0010 WS2_32!connect (FPO: [Non-Fpo]) 00ebc87c 76e5cad5 00462758 00ebc8a4 0185 wldap32!LdapParallelConnect+0x2e3 (FPO: [Non-Fpo]) 00ebca70 76e597a2 00462758 004568a0 wldap32!ConnectToSRVrecs+0x21b (FPO: [Non-Fpo]) 00ebcac8 76e59688 00462758 wldap32!OpenLdapServer+0x612 (FPO: [Non-Fpo]) 00ebcae8 76e62ca9 00462758 wldap32!LdapConnect+0x2cf (FPO: [Non-Fpo]) 00ebcb58 76e63021 00432670 76e8e158 wldap32!LdapChaseReferral+0xb27 (FPO: [Non-Fpo]) 00ebcb98 76e62e1d 0042ca00 004328b0 00432670 wldap32!HandleReferral+0x7ac (FPO: [Non-Fpo]) 00ebcbd4 76e553e2 0042cab8 00ebcc04 wldap32!HandleReferrals+0x151 (FPO: [Non-Fpo]) 00ebcc08 76e5b0f8 0042cab8 0005 0001 wldap32!ldap_result_with_error+0x30e (FPO: [Non-Fpo]) 00ebcc3c 76e5e584 0042cce4 80039620 0002 wldap32!ldap_search_ext_sW+0x87 (FPO: [Non-Fpo]) 00ebcc80 76e5e783 0042cce4 80039620 0002 wldap32!ldap_search_stW+0x45 (FPO: [Non-Fpo]) 00ebcca8 610818e2 0042cce4 80039620 0002 wldap32!ldap_search_sW+0x21 (FPO: [Non-Fpo]) I can see this occurring with ldp.exe (from Windows Server 2003 support tools; also works on newer version of windows) and netstat.exe Connection-Connect (default server, default port 389) (1 TCP/IP session to DC1:389) Connection-Bind (enter username and password) (no new sessions) Browse-Search Base Dn - first naming context Filter: ((objectClass=trustedDomain)(name=wibble)) Gets 0 entries, quickly, no extra sessions visible Click 'Options' Select 'Chase Referrals' Click Ok Search again. Gets 0 entries, takes some seconds, and establishes nuermous TCP/IP connections. (1) LDAP_OPT_REFERRALS is on by default (2) The fix added CN=System to the Base Dn - this seems to turn off referrals -- *aside* Sysinternals ADInsight is a 32bit only tool and, in order to work on a 64bit Windows you seem to have to manually inject the DLL ADInsightDll.dll (which is extracted into %TEMP%) into the target (32-bit!) process. Regards, Roger. From: Roger Orr Sent: 18 February 2015 11:26 To: Corinna Vinschen Cc: cygwin@cygwin.com Subject: RE: slow startup after upgrade Hello Corinna, I've just been trying out both the 2015-02-18 10:30:19/44 UTC and 2015-02-17 21:27:23/48 UTC patches. Both are now down to the same timings as with a 'files' entry in /etc/nsswitch.cfg, (and there's no detectable speed difference between them.) The scope restriction in the second query to \System reduces the query time to 1.1 - 1.3 ms (was 4 seconds) and also it no longer opens 14 TCP/IP sessions to various ldap servers around the planet (!) I note that mkpasswd and mkgroup do still open many sessions to the ldap servers, but that may be inevitable. It's not an issue directly, of course, since I'll no longer need to make use of these, but it perhaps might indicate another place where the ldap queries are sub-optimal. Thanks for your rapid response on this issue! Regards, Roger. From: Corinna Vinschen [corinna-cyg...@cygwin.com] Sent: 18 February 2015 11:18 To: cygwin@cygwin.com Cc: Roger Orr Subject: Re: slow startup after upgrade Hi Roger, On Feb 17 22:32, Corinna Vinschen wrote: On Feb 17 19:13, Roger Orr wrote: According to nltest /dclist: Our environment has 6 London based DCs According to ldp.exe Live Enterprise Tree we have a tree structure for LDAP. 6 leaf nodes at the top matching ther 6 DCs 4 leaf nodes under an AUS (Australia) node 3 leaf nodes under a CHI (Chicago) node and a few more similar to this in other regions. When running mkpasswd I see active sessions to all the nodes in the tree on port 389 (ldap) I have tried using Sysinternals ADInsight (with a 32bit cygwin) to see what requests are made with 'echo.exe' There are two searches shown: A) RootDSE:LDAP_SCOPE_BASE:(objectclass=*) (1.113ms) B) London DNS:LDAP_SCOPE_SUBTREE:((objectClass=trustedDomain) AND (name=Australian DNS)) (4.426s) I don't know why the second query is being made with the Australian DNS name but I suspect this is the problem. Thanks for doing that! It's really cool to get this info since it seems to point to the culprit. It's not the problem that the Australian DNS is mentioned here. This is perfectly valid. The LDAP query is going to the London DNS DC (apparently, I hope that's right in your case) and the query is for information on a trusted domain. It looks like you have a group from the australian domain in your user token. To compute the gid of the group, cygwin asks *your* DC for a value called posixOffset for *that* trusted domain. The bottom line
RE: slow startup after upgrade
Hello Corinna, I've just been trying out both the 2015-02-18 10:30:19/44 UTC and 2015-02-17 21:27:23/48 UTC patches. Both are now down to the same timings as with a 'files' entry in /etc/nsswitch.cfg, (and there's no detectable speed difference between them.) The scope restriction in the second query to \System reduces the query time to 1.1 - 1.3 ms (was 4 seconds) and also it no longer opens 14 TCP/IP sessions to various ldap servers around the planet (!) I note that mkpasswd and mkgroup do still open many sessions to the ldap servers, but that may be inevitable. It's not an issue directly, of course, since I'll no longer need to make use of these, but it perhaps might indicate another place where the ldap queries are sub-optimal. Thanks for your rapid response on this issue! Regards, Roger. From: Corinna Vinschen [corinna-cyg...@cygwin.com] Sent: 18 February 2015 11:18 To: cygwin@cygwin.com Cc: Roger Orr Subject: Re: slow startup after upgrade Hi Roger, On Feb 17 22:32, Corinna Vinschen wrote: On Feb 17 19:13, Roger Orr wrote: According to nltest /dclist: Our environment has 6 London based DCs According to ldp.exe Live Enterprise Tree we have a tree structure for LDAP. 6 leaf nodes at the top matching ther 6 DCs 4 leaf nodes under an AUS (Australia) node 3 leaf nodes under a CHI (Chicago) node and a few more similar to this in other regions. When running mkpasswd I see active sessions to all the nodes in the tree on port 389 (ldap) I have tried using Sysinternals ADInsight (with a 32bit cygwin) to see what requests are made with 'echo.exe' There are two searches shown: A) RootDSE:LDAP_SCOPE_BASE:(objectclass=*) (1.113ms) B) London DNS:LDAP_SCOPE_SUBTREE:((objectClass=trustedDomain) AND (name=Australian DNS)) (4.426s) I don't know why the second query is being made with the Australian DNS name but I suspect this is the problem. Thanks for doing that! It's really cool to get this info since it seems to point to the culprit. It's not the problem that the Australian DNS is mentioned here. This is perfectly valid. The LDAP query is going to the London DNS DC (apparently, I hope that's right in your case) and the query is for information on a trusted domain. It looks like you have a group from the australian domain in your user token. To compute the gid of the group, cygwin asks *your* DC for a value called posixOffset for *that* trusted domain. The bottom line is, this is not going to Australia, because all DCs have this info for their trusted domains in their own DB so it's a planly local query. However, that mean this local LDAP query is *extremly* slow. I changed the query now to limit the scope of the database search. This should speed up the request a lot. [...etc...] I just release a new test release, 1.7.35-0.3, see https://cygwin.com/ml/cygwin-announce/2015-02/msg00133.html This should speed up the search for the trustedDomain info a lot. Can you please give it a try and perform your fantastic timing test as above? Thanks in advance, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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
RE: slow startup after upgrade
and also it no longer opens 14 TCP/IP sessions to various ldap servers around the planet (!) Uh, that might be the result of the other changes which don't open an LDAP connection to fetch group info. 14 connections probably means, you're in 14 groups in other domains than your login domain. There weren't any other LDAP requests logged (I was testing with the first patch 1.7.35-0.1 that reduced the time for running echo.exe from 120s to 4.5s) so I don't think it was related to another query. I may be able to test this out again tomorrow and get the call stacks of the connect calss. Incidentally how can you tell the patch level of cygwin1.dll -- the DLL versions all seem to be 1007.35.0.0 ? Regards, Roger. -- 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
RE: slow startup after upgrade
Corinna Vinschen wrote: On Feb 16 20:02, Roger Orr wrote: Corinna Vinschen wrote: So I'd think the best way forward is to update to the 1.7.35-0.1 test release and report further from there. Thanks, this does help a little. However I will still be using the 'files' setting. The idea was to test this stuff to find a better solution which is acceptable. If you simply revert to files without helping to test we'll probably never find the culprit. I'm very happy to continue testing; I was merely meaning the 1.7.35 performance is still not adequate in my environment. It would be nice to know what part of the code is so slow. The LookupAccountSid calls shouldn't be so slow because they only fetch information already cached on the local machine. So it's probably the LDAP call. Why does an LDAP call take 4 secs?!? Are you remote from your DC, by any chance? I have made some progress with analysis (slightly handicapped as I'm a novice with ldap and am not an admin) According to nltest /dclist: Our environment has 6 London based DCs According to ldp.exe Live Enterprise Tree we have a tree structure for LDAP. 6 leaf nodes at the top matching ther 6 DCs 4 leaf nodes under an AUS (Australia) node 3 leaf nodes under a CHI (Chicago) node and a few more similar to this in other regions. When running mkpasswd I see active sessions to all the nodes in the tree on port 389 (ldap) I have tried using Sysinternals ADInsight (with a 32bit cygwin) to see what requests are made with 'echo.exe' There are two searches shown: A) RootDSE:LDAP_SCOPE_BASE:(objectclass=*) (1.113ms) B) London DNS:LDAP_SCOPE_SUBTREE:((objectClass=trustedDomain) AND (name=Australian DNS)) (4.426s) I don't know why the second query is being made with the Australian DNS name but I suspect this is the problem. (Perhaps it as simple as A coming first in the alphabet ...) Happy to investigate further if someone can suggest some useful avenues. Regards, Roger. -- 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
RE: slow startup after upgrade
Corinna Vinschen wrote: So I'd think the best way forward is to update to the 1.7.35-0.1 test release and report further from there. Thanks, this does help a little. However I will still be using the 'files' setting. Here are some results in case they're of interest. (Windows 7/64 with cygwin/64.) 1) Running cygwin echo.exe from a cmd.exe command shell a) With passwd: files and group: files in /etc/nsswitch.conf 0.03 - 0.4 s b) With 1.7.34 and default /etc/nsswitch.conf around 120s C) With 1.7.35 and default /etc/nsswitch.conf 4.4 - 4.6s 2) mkgroup 1.7.34 took 46m 4s 1.7.35 took 39s output is 53kb, 681 lines 3) mkpasswd 1.7.34 took 1h 14m 6s 1.7.35 took 59m 0s output is 132kb, 1081 lines Regards, Roger. -- 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
RE: slow startup after upgrade
I am also hit by the slow AD issue; so thanks for the solution. mkpasswd takes an hour and mkgroup takes longer -- is there anything I can suggest to our administrators that would help make this time less? We have not had previous problems reported with our AD being slow. Regards, Roger. -Original Message- From: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com] Sent: 11 February 2015 08:53 To: cygwin@cygwin.com Subject: Re: slow startup after upgrade On Feb 10 15:52, Warren Young wrote: On Feb 10, 2015, at 2:38 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: Starting a Cygwin shell is slow, what's going on? I'd not be overly grudgy if somebody wants to come up with a FAQ text. I'm not entirely sure I understand the problem, but I've attached a starting point. I'm pretty sure the issue brought up in this thread isn't the only possible cause of slow launches. DNS can do it, too, and I suspect if I wracked my brain some more on it, I could come up with other causes. The DocBook isn't validated. It may need to be adjusted before it will let the FAQ document build correctly. It might also be good to include olinks or ulinks to other parts of the Cygwin docs. Thanks a lot. I added this to the FAQ in CVS with just the changes necessary to make it a FAQ entry. If somebody has to add something, feel free to send text. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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
