#2344 MSYS utilities very slow to start for domain users

[Alex Freidin]

MSYS utilities take a long time to start on certain machines. In my case a startup delay is 21sec. It turns out that MSYS DLL tries to get user information in function internal_getlogin() located in MSYS runtime at winsup/cygwin/uinfo.cc. It does two calls to NetUserGetInfo(), one for local host that returns error for a domain account and another to a domain controller (DC) that is read from LOGONSERVER variable. Note that LOGONSERVER is only updated at Login. If DC is not reachable, either because the machine is offline, on another network or the DC hostname changed since login, then the second call takes 21sec until it fails on timeout. MSYS utility will then start shortly.
This problem has already been reported and fixed in MSYS2 version of uinfo.cc. The patch for uinfo.cc from 22/10/2001 has the following code:
https://sourceforge.net/p/mingw/msys2-runtime/ci/28fe7848120e417078d4fca90ca02df84f47b736/tree/winsup/cygwin/uinfo.cc#l89

Patch suggested by Ian Ray ian.ray@nokia.com:

• syscalls.cc (seteuid): Unset environment variables HOMEDRIVE and
  HOMEPATH before calling internal_getlogin().
• uinfo.cc (internal_getlogin): Use default HOMEPATH and HOMEDRIVE
  from environment if both are present, else query NetUserGetInfo().

/* NetUserGetInfo() can be slow in NT domain environment, thus we

       * only obtain HOMEDRIVE and HOMEPATH if they are not already set
       * in the environment. */
      if (!getenv ("HOMEPATH") || !getenv ("HOMEDRIVE"))

Here, I found a discussion on this fix and it looks like it was supposed to be applied to MSYS-1.0 DLL, but I don't see this fix in MSYS code, only in MSYS2 history of uinfo.cc.
https://groups.google.com/forum/#!topic/msysgit/6-UcIbEK5j4

Please help to apply this fix to MSYS. This problem is very annoying.

[Alex Freidin]

Forgot to mention that a delay is when the utilities are launched not from the bash shell. For example, when using MinGW with Eclipse CDT. Or, when launching bash shell itself.

[Cesar Strauss]

Hello Alex,

Thanks for the report. I'll apply a fix based on the information you provided. I'll tell you when it is ready for you to test.

The problem was fixed in Cygwin a long time ago. The reason you see the fix in MSYS2 history is because it is derived from a recent version of Cygwin, so they share a common history. MSYS does not contain the fix, because it is based on an ancient version of Cygwin. The fix was applied to Cygwin only after MSYS and Cygwin histories diverged.

For some time, the msysGit project distributed their version of MSYS-1.0 DLL, based on our own. It seems they found the problem and created a fix for themselves. They used to submit some of their changes to us, but not this particular one,

Thanks,

Cesar

[Alex Freidin]

Thank you Cesar. Now, it is clear how the fix got into other packages.
I will check the fix when it's ready.

[Cesar Strauss]

Hello Alex,

Can you try the attached DLL?

Regards,

Cesar

[Cesar Strauss]

Here is the patch relative from 1.0.19, for reference.

[Alex Freidin]

Hello Cesar,
Sorry for delayed answer. I couldn't reproduce the scenario for some time. My problem was on VM whose domain controller changed and therefore couldn't be reached and caused the delay. I restarted it as a workaround and it stopped reproducing the problem.
Now, I've got another VM with this issue and confirm that the attached DLL fixes the problem.
Thanks a lot. Hope it will be included in the official MinGW release.

Alex