Are you using LDAP to connect to your computer? If yes, this is similarly related to this issue, but I'm not 100% sure.

To test that you are facing the same issue, you could create a /etc/passwd with your account information so they are not fetch from Windows directly. This should be fairly simple to test it out, however, I never did it myself yet.

Information in this thread or on cygwin's nsswitch.conf could prove useful. Maybe others have a fairly simple cookbook to follow.

I using Windows by logging in with domain user.

I created /etc/passwd and /etc/group files using mkgroup and mkpasswd utilities. They include all groups and usernames that were in "strace ls" output (and more, but that's irrelevant). But running "ls" is still slow. "strace ls" now show this:

   12   43607 [main] ls 14816 dtable::extend: size 32, fds 0x1802FB3E8
  236   43843 [main] ls 14816 transport_layer_pipes::connect: Try to connect to named pipe: \\.\pipe\msys-07c9b4f1c823d951-lpc
   39   43882 [main] ls 14816 transport_layer_pipes::connect: Error opening the pipe (2)
   21   43903 [main] ls 14816 client_request::make_request: cygserver un-available
--- Process 14816, exception 00000000 at 000007FEFD22940D
1459351 1503254 [main] ls 14816 reg_key::build_reg: failed to create key ServicesForNFS in the registry
966780 2470034 [main] ls 14816 cygheap_user::ontherange: what 2, pw 0x1802FB6B8
   41 2470075 [main] ls 14816 cygheap_user::ontherange: HOME is already in the environment /home/USERNAME
   96 2470171 [main] ls 14816 build_argv: argv[0] = 'ls'
10469 2480640 [main] ls 14816 build_argv: argc 1

As you can see it has no more "pwdgrp::fetch_account_from_windows" lines. But there are still errors:

1. something about connecting to named pipe + cygserver
2. something about failure to create registry key + ServicesForNFS

• if it's running anything over a network like a network share, you can expect significant lag
• if it's 32-bit code running on a 64-bit box, you can expect the virtualization (WOW64) to slow the program down. but hopefully not that much on a local box, especially if it's in the OS's internal disk cache in RAM. first access will be slow, subsequent accesses should be much faster due to disk cache, but the virtualization thing is another hurdle, however it doesn't slow things down too much I should think.

my case is slightly different; for me msys is slow on starting and on bash completion; but "ls" is fast

see http://sourceforge.net/p/msys2/discussion/general/thread/87925e6f/

i also tried to create passwd/group; "mkgroup -d" doesn't output group from domain

i "solved" disabling db in nsswitch.conf

ok.

This is great. Commenting out "db" from nsswitch.conf helps. Now all operations are fast for me.

Disabling db from both passwd and group fixed the issue but led to my username being unrecognised (bash prompt showed me as Unknown+User). However, the "fix" was to just disable db from group and leave passwd as it was, and this sped up MSYS2 utilities like diff, which, ls and also the startup of MSYS2 significantly.

unfortunately now some commands are slower than some time ago; for example: ls, git status/diff, configure (autoreconf), gitk

re-enabling db in nsswitch.conf makes these commands again fast; but it slows bash completion (TAB); the start of msys2_shell.bat is quite normal

@KrullKorg Bash completion being slow has got nothing to do with MSYS2 itself. See here for an explanation.

as i wrote bash completion isn't slow with db disabled in nsswitch.conf and slow if db is enabled; tomorrow i'll try again, to be sure

of course I'm talking about a pc under ms (samba) domain; at home it works perfectly

and yes i know that msys2 derived from cygwin

i just tried under latest cygwin (1.7.5) and it works perfectly

Notable differences between MSYS2 and Cygwin:

• the current MSYS2 runtime is based on Cygwin trunk from April 10th, not on Cygwin release
• MSYS2 doesn't include cygserver and other Cygwin system integration tools

Can you look at differences between your Cygwin and MSYS2 installs? Namely /etc/passwd, /etc/group, /etc/nsswitch.conf, /etc/fstab, output of mount, a cygserver process running. MSYS2 should take advantage the same caching mechanisms as Cygwin, at least within a process tree.

I'm sorry I'm dumping all the debugging on you, but I don't currently have any domain to join here.

i don't have /etc/passwd, /etc/group and cygserver in both msys2 and cygwin

FSTAB - CYGWIN

# /etc/fstab
#
#    This file is read once by the first process in a Cygwin process tree.
#    To pick up changes, restart all Cygwin processes.  For a description
#    see https://cygwin.com/cygwin-ug-net/using.html#mount-table

# This is default anyway:
none /cygdrive cygdrive binary,posix=0,user 0 0

FSTAB - MSYS2

# For a description of the file format, see the Users Guide
# http://cygwin.com/cygwin-ug-net/using.html#mount-table

# DO NOT REMOVE NEXT LINE. It remove cygdrive prefix from path
none / cygdrive binary,posix=0,noacl,user 0 0

NSSWITCH - CYGWIN

# /etc/nsswitch.conf
#
#    This file is read once by the first process in a Cygwin process tree.
#    To pick up changes, restart all Cygwin processes.  For a description
#    see https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch
#
# Defaults:
# passwd:   files db
# group:    files db
# db_home:  cygwin desc
# db_shell: cygwin desc
# db_gecos: cygwin desc

NSSWITCH - MSYS2

# Begin /etc/nsswitch.conf

passwd: files db
group: files db

db_enum: cache builtin

db_home: cygwin desc
db_shell: cygwin desc
db_gecos: cygwin desc

# End /etc/nsswitch.conf

MOUNT - CYGWIN

C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin64 on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
I: on /cygdrive/i type smbfs (binary,posix=0,user,noumount,auto)
K: on /cygdrive/k type ntfs (binary,posix=0,user,noumount,auto)
O: on /cygdrive/o type smbfs (binary,posix=0,user,noumount,auto)
V: on /cygdrive/v type smbfs (binary,posix=0,user,noumount,auto)
X: on /cygdrive/x type smbfs (binary,posix=0,user,noumount,auto)
Z: on /cygdrive/z type sshvfs (binary,posix=0,user,noumount,auto)

MOUNT - MSYS2

C:/msys64 on / type ntfs (binary,noacl,auto)
C:/msys64/usr/bin on /bin type ntfs (binary,noacl,auto)
C: on /c type ntfs (binary,noacl,posix=0,user,noumount,auto)
I: on /i type smbfs (binary,noacl,posix=0,user,noumount,auto)
K: on /k type ntfs (binary,noacl,posix=0,user,noumount,auto)
O: on /o type smbfs (binary,noacl,posix=0,user,noumount,auto)
V: on /v type smbfs (binary,noacl,posix=0,user,noumount,auto)
X: on /x type smbfs (binary,noacl,posix=0,user,noumount,auto)
Z: on /z type sshvfs (binary,noacl,posix=0,user,noumount,auto)

PS: i just tried to remove db_enum from nsswitch.conf in msys2
PPS: don't worry about ask info; i'm happy to help msys2

Can you try to mount cygdrive in Cygwin with noacl? I don't see why noacl would make things slower, but it's worth a shot.

I'm assuming you're trying ls somewhere inside /c/ (/cygdrive/c/) and not inside /home/ or somewhere like that.

i changed /etc/fstab in cygwin but i got the same behavior adding noacl: it's fast

and same behavior both in /home/ and in /c/

i also tried to remove noacl in msys2, but without improvements

I'm out of ideas at this point. I don't know enough about Cygwin internals to suggest a good test for you. You can try searching the Cygwin mailing list, maybe some of the information there will apply to your situation.

i just tried on a relative new pc (virtual machine) with windows 10 tp (under the same domain) and it seems to work...

i installed msys2 from exe; then i upgraded with pacman -Syu

so i'll try to use a clean windows 8.1 vm... maybe the problem is the windows version... or my pc

i really think it's the fault of my pc; i tried also with windows 8 and it works

i found on strace executed on my pc this error (that isn't present in virtual machines)

2388701 3040772 [main] ls 7032 pwdgrp::fetch_account_from_windows: LookupAccountSid(S-1-5-21-726227932-2052316878-829958588-513), Win32 error 1789

Interesting. KB976494 says the error is ERROR_TRUSTED_RELATIONSHIP_FAILURE "The trust relationship between this workstation and the primary domain failed.", so this could be a bug in Windows, or your domain connection is borked.

Can you try to leave and re-join the domain?

yes i arrived at the same conclusion, and it worked

I also faced the same issue with KrullKorg and legends2k's case.
I found that expansion of ~* was very slow.
I had to update /etc/passwd and /etc/group, then disable db in nsswitch.conf.
More detail: https://gist.github.com/k-takata/9b8d143f0f3fef5abdab

Very nice summary, @k-takata.

@k-takata your workaround gist works great until I disconnect from the domain and hop onto another network... then it's slow again.

I found that pacman installs are really slow until I applied @k-takata 's workaround. I wonder why it's so slow for it to do lookups on the domain?

And why no cygserver? Cannot run now postgresql. Error like function is not implemented.

Even after changing nsswitch.conf things are still a bit slow after dropping off an AD network. I found that disabling network and then re-enabling (using my laptop hardware button) made things responsive again.

With a new msys2 installation today, I observed every process, the initial bash.exe spawned by mintty.exe as well as every process spawned by bash, taking ~1s to ~3s to start. strace bash 2>&1 | ts revealed all the time was spent before the first line out of output from strace, suggesting it was part of the process startup itself.

I tried the nsswitch.conf technique in the comments above but it did not change anything. (I believe Cygwin had got a patch to make the workaround unnecessary, and perhaps msys2 has had that same patch as well.)

So I traced bash.exe through procmon and observed it spending ~500ms on every startup enumerating ~8k files that match C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\*.cat, each with a callstack containing appid.sys (the AppLocker driver). That led me to this page, and indeed my machine has AppLocker policies enabled (*). After code-signing all binaries under C:\msys64\usr\bin as that page suggests (cd C:\msys64\usr\bin\; gci -re *.exe | %{ &'C:\Program Files (x86)\Windows Kits\8.1\bin\x64\signtool.exe' sign /a /uw $_.FullName }), all msys2 process start nearly instantaneously.

(*) secpol.msc actually says there are no AppLocker policies, but Get-AppLockerPolicy -Effective clearly lists several.

Thanks for the info. Does this mean every time an executable under /usr/bin (, /mingw64/bin or /mingw32/bin) changes or new ones get added, the signtool has to be rerun?

Yes. Signing adds a signature to the executable, so if the executable changes it'll need to be signed again.

@i2000s
i try many ways and it has no help, then i try to close my AV, evething works!
3ks!

@i2000s
i try many ways and it has no help, then i try to close my AV, evething works!
3ks!

@RonaldinhoL
Yes, your AV scans most of the utilities every time, if they're not signed and in an internal database with checksums, to make sure they don't harm your system. You should be able to exclude your MSYS2 installation from scanning. AV software and similar security applications can be a nightmare for developers.

I've been encountering this exact same slowdown, but the nsswitch.conf changes have not helped. What else may be tried?

I was able to reproduce this in a Windows 7 virtual machine. After doing an upgrade with pacman -Syu followed by restarting the shell and running pacman -Su, solved the problem for me.

On my friend's Windows 10 machine, updating did not help.

I definitely think there's a culprit deep in some policies somewhere, between windows and linux, the same bash script runs ~50x faster on linux than it does on windows...I don't think it is I/O bound and I don't think it is a problem with AD lookups on files. AV was completely "off" although granted I have noticed in past "off" does not mean actually unloaded, sometimes that requires a reboot...

And yet I was able to forkbomb the system relatively slowly, meaning whichever system is ultimately a useless slowdown (as it is doing something un-necessary and unhelpful).

@Arnavion I didn't have a signing cert, I tried signing (not sure I did it correctly), nevertheless bash shows a large, large number of registry keys being opened. Trying a couple more updates before I dive further....

I too experienced extreme slowness on Win 10. This fixed it for me:

mkpasswd > /etc/passwd
mkgroup > /etc/group

Then comment out mentions of db in /etc/nsswitch.conf and restart msys2. Moving at a usable clip now.

I too experienced extreme slowness on Win 10. This fixed it for me:

mkpasswd > /etc/passwd
mkgroup > /etc/group

Then comment out mentions of db in /etc/nsswitch.conf and restart msys2. Moving at a usable clip now.

Tried this and not sure if it made a difference yet. Need to run performance tests for comparison. I think most people could use this fix and it could be applied to the MSYS2 installer if it really does make a difference.

@Arnavion I don't have a C:\msys64\usr\bin path, I tried to run the SignTool at C:\SysGCC\mingw64\bin but got this error:
SignTool Error: No certificates were found that met all the given criteria.

gci -re *.exe | %{ &'C:\Program Files (x86)\Windows Kits\8.1\bin\x64\signtool.exe' sign /a /uw $_.FullName }

I run your command on powershell on Windows 10. What's not right in the command here?

Tried this and not sure if it made a difference yet. Need to run performance tests for comparison. I think most people could use this fix and it could be applied to the MSYS2 installer if it really does make a difference.

For me, it was also necessary (besides modifying nssswitch.conf and adding /etc/passwd and /etc/group to switch to the offline (local) account in Windows 11 (had online because of joining the insider's program to test WSLg; not needed anymore). Still quite slow, but about 5x faster (no exaggeration) than before.

I think the AV is called Avast. I have uninstalled it.

Rather than removing AV entirely, try excluding the path mounted on /bin from scanning. You can run mount to display the Windows path.

Slow +1

I've tried both disabling the bash completion as well as the db in the nsswitch file... nothing changes, still very slow.
The weird thing is that it was fine about a month ago and it just suddenly grinds to a halt out of no where.

I am on Windows 11 and there had been several Windows updates being applied... maybe this is related to some Windows updates...? sigh

The issue for Bash run this way is someone needs to modify Bash itself to fit more into how Windows is designed to handle subprocesses and other concerns. There's no way around that. Until that happens this will always be slow.

The issue for Bash run this way is someone needs to modify Bash itself to fit more into how Windows is designed to handle subprocesses and other concerns. There's no way around that. Until that happens this will always be slow.

Are we sure is bash? I just noticed something, when I run make it throws tons of exception in the background? I am not exactly sure what I'm doing, but I ran a strace make (because that's what was being super slow).

And it looks like internally it spwns a bash shell and then it throws an insane amount of "internal exception"?

--- Process 14120 created
 3079   77327 [main] make 5649 child_info_spawn::worker: pid 5649, prog_arg /bin/bash, cmd line C:\msys64\usr\bin\bash.exe -c "echo  | cut -d- -f3")
--- Process 14120 loaded C:\Windows\System32\ntdll.dll at 00007ffb23350000
 1367   78694 [main] make 5649! child_info_spawn::worker: new process name \\?\C:\msys64\usr\bin\bash.exe
 2674   81368 [main] make 5649! child_info_spawn::worker: spawned windows pid 14120
  323   81691 [main] make 5649! child_info::sync: n 2, waiting for subproc_ready(0x218) and child process(0x224)
--- Process 14120 (pid: 5649) loaded C:\Windows\System32\kernel32.dll at 00007ffb22350000
--- Process 14120 (pid: 5649) loaded C:\Windows\System32\KernelBase.dll at 00007ffb207e0000
--- Process 14120 (pid: 5649) thread 4020 created
--- Process 14120 (pid: 5649) loaded C:\Windows\System32\user32.dll at 00007ffb21360000
--- Process 14120 (pid: 5649) loaded C:\msys64\usr\bin\msys-2.0.dll at 0000000180040000
--- Process 14120 (pid: 5649) loaded C:\Windows\System32\win32u.dll at 00007ffb21060000
--- Process 14120 (pid: 5649) thread 8148 created
--- Process 14120 (pid: 5649) thread 6616 created
--- Process 14120 (pid: 5649) loaded C:\Windows\System32\gdi32.dll at 00007ffb22e10000
--- Process 14120 (pid: 5649) loaded C:\Windows\System32\gdi32full.dll at 00007ffb20d80000
--- Process 14120 (pid: 5649) loaded C:\Windows\System32\msvcp_win.dll at 00007ffb20fc0000
--- Process 14120 (pid: 5649) loaded C:\Windows\System32\ucrtbase.dll at 00007ffb20ea0000
    1       1 [main] bash (14120) **********************************************
  308     309 [main] bash (14120) Program name: C:\msys64\usr\bin\bash.exe (windows pid 14120)
  263     572 [main] bash (14120) OS version:   Windows NT-10.0
  307     879 [main] bash (14120) **********************************************
--- Process 14120 (pid: 5649) loaded C:\Windows\System32\advapi32.dll at 00007ffb21a00000
--- Process 14120 (pid: 5649) loaded C:\Windows\System32\msvcrt.dll at 00007ffb22a30000
--- Process 14120 (pid: 5649) loaded C:\Windows\System32\sechost.dll at 00007ffb212b0000
--- Process 14120 (pid: 5649) loaded C:\Windows\System32\rpcrt4.dll at 00007ffb22e40000
--- Process 14120 (pid: 5649) loaded C:\Windows\System32\cryptbase.dll at 00007ffb1ffa0000
--- Process 14120 (pid: 5649) loaded C:\Windows\System32\bcryptprimitives.dll at 00007ffb20d00000
23493   24372 [main] bash (14120) sigprocmask: 0 = sigprocmask (0, 0x0, 0x18031C470)
  484   24856 [main] bash (14120) child_copy: cygheap - hp 0x21C low 0x800000000, high 0x80000D3F0, res 1
  270   25126 [main] bash (14120) child_copy: done
  321   25447 [main] bash (14120) open_shared: name shared.5, shared 0x1A0000000 (wanted 0x1A0000000), h 0x11C, m 0, created 0
  283   25730 [main] bash (14120) user_heap_info::init: heap base 0xA00000000, heap top 0xA00000000, heap size 0x20000000 (536870912)
  353   26083 [main] bash (14120) open_shared: name (null), shared 0x1A1000000 (wanted 0x1A1000000), h 0x120, m 1, created 0
  267   26350 [main] bash (14120) user_info::create: opening user shared for '' at 0x1A1000000
  264   26614 [main] bash (14120) user_info::create: user shared version AB1FCCE8
  314   26928 [main] bash (14120) open_shared: name (null), shared 0x1A2000000 (wanted 0x1A2000000), h 0x214, m 2, created 0
  308   27236 [main] bash 5649 pinfo::thisproc: myself dwProcessId 14120
  324   27560 [main] bash 5649 open_shared: name (null), shared 0x1A3000000 (wanted 0x1A3000000), h 0x194, m 3, created 0
  283   27843 [main] bash 5649 open_shared: name cygpid.1995, shared 0x1A4000000 (wanted 0x1A4000000), h 0x128, m 6, created 0
  349   28192 [main] bash 5649 fhandler_base::fixup_after_exec: here for 'pipe:[51539614328]'
  305   28497 [main] bash 5649 open_shared: name cygpid.1995, shared 0x1A4010000 (wanted 0x1A4010000), h 0x128, m 6, created 0
  333   28830 [main] bash 5649 fhandler_base::fixup_after_exec: here for '/c/Users/et5341/source/windows/mystuff/Makefile'
  226   29056 [main] bash 5649 fhandler_base::fixup_after_exec: here for '/c/Users/et5341/source/windows/mystuff/cis.mk'
  191   29247 [main] bash 5649 fhandler_base::fixup_after_exec: here for '/c/Users/et5341/source/windows/mystuff/colours.mk'
  218   29465 [main] bash 5649 fhandler_base::fixup_after_exec: here for 'pipe:[51539614328]'
  264   29729 [main] bash 5649 fhandler_base::fixup_after_exec: here for 'pipe:[51539614328]'
  267   29996 [main] bash 5649 child_info::ready: signalled 0x218 that I was ready
66070  147761 [main] make 5649! child_info::sync: pid 14120, WFMO returned 0, exit_code 0x103, res 1
  334   30330 [main] bash 5649 fhandler_pipe::create: name \\.\pipe\msys-dd50a72ab4668b33-14120-sigwait, size 11440, mode PIPE_TYPE_MESSAGE
  420  148181 [main] make 5649! fhandler_base::close_with_arch: line 1181:  /dev/cons0<0x800008AB0> usecount + -1 = 2
  348   30678 [main] bash 5649 fhandler_pipe::create: pipe read handle 0x130
  348  148529 [main] make 5649! fhandler_base::close_with_arch: not closing archetype
  284   30962 [main] bash 5649 fhandler_pipe::create: CreateFile: name \\.\pipe\msys-dd50a72ab4668b33-14120-sigwait
  399  148928 [main] make 5649! fhandler_pipe::release_select_sem: close(PIPEW) release 2
  439   31401 [main] bash 5649 fhandler_pipe::create: pipe write handle 0x134
  341  149269 [main] make 5649! fhandler_base::close: closing 'pipe:[51539614328]' handle 0x2A8
  336   31737 [main] bash 5649 dll_crt0_0: finished dll_crt0_0 initialization
  364  149633 [main] make 5649! fhandler_base::close_with_arch: line 1181:  /dev/cons0<0x800008AB0> usecount + -1 = 1
  376  150009 [main] make 5649! fhandler_base::close_with_arch: not closing archetype
  326  150335 [main] make 5649! fhandler_base::close: closing '/c/Users/et5341/source/windows/mystuff/Makefile' handle 0x154
  363  150698 [main] make 5649! fhandler_base::close: closing '/c/Users/et5341/source/windows/mystuff/cis.mk' handle 0x15C
  296  150994 [main] make 5649! fhandler_base::close: closing '/c/Users/et5341/source/windows/mystuff/colours.mk' handle 0x160
  246  151240 [main] make 5649! fhandler_pipe::release_select_sem: close(PIPER) release 2
  247  151487 [main] make 5649! fhandler_base::close: closing 'pipe:[51539614328]' handle 0x170
  304  151791 [main] make 5649! fhandler_pipe::release_select_sem: close(PIPEW) release 1
--- Process 14120 (pid: 5649) loaded C:\Windows\System32\imm32.dll at 00007ffb230b0000
  392  152183 [main] make 5649! fhandler_base::close: closing 'pipe:[51539614328]' handle 0x17C
 3372  155555 [main] make 5649! proc_terminate: child_procs count 0
  327  155882 [main] make 5649! proc_terminate: leaving
  300  156182 [main] make 5649! pinfo::maybe_set_exit_code_from_windows: pid 5649, exit value - old 0x0, windows 0xDEADBEEF, MSYS 0x0
  354  156536 [main] make 5649! pinfo::exit: Calling dlls.cleanup_forkables n 0x4000000, exitcode 0x0
  303  156839 [main] make 5649! pinfo::exit: Calling ExitProcess n 0x4000000, exitcode 0x0
--- Process 14120 (pid: 5649), exception c0000005 at 0000000000000000
--- Process 12384 thread 14088 exited with status 0x0
--- Process 12384 thread 19736 exited with status 0x0
--- Process 12384 thread 17044 exited with status 0x0
--- Process 12384 thread 3152 exited with status 0x0
--- Process 14120 (pid: 5649), exception c0000005 at 00000001800616fc
--- Process 12384 exited with status 0x0
--- Process 14120 (pid: 5649), exception c0000005 at 00000001800616fc
--- Process 14120 (pid: 5649), exception c0000005 at 00000001800616fc
--- Process 14120 (pid: 5649), exception c0000005 at 00000001800616fc
--- Process 14120 (pid: 5649), exception c0000005 at 00000001800616fc
^^^^ this same exception with exact same code goes on for like a few hundreds lines ^^^^

Thoughts?

msys2 is extremely slow as a domain user, what happens if I disable db from nsswitch what are the consequences?
disabled db, still slow, maybe it is the code signing thing. no idea

msys2 in general is slow due to the POSIX emulation layer that it must do to translate ALL posix api's into Window's API

this INCLUDES the IO drivers and console input/output drivers among other heavy drivers/layers

@mgood7123, folks know. You are speaking about the general picture. And this issue is about the slow speed getting even slower – the particular cases.

PS. Midipix is a bit faster because it uses NTAPI during the translation.

msys2 in general is slow due to the POSIX emulation layer that it must do to translate ALL posix api's into Window's API

this INCLUDES the IO drivers and console input/output drivers among other heavy drivers/layers

I was talking about msys2 as a domain user, msys2 on normal windows installations is quick, so there is some networking happening, idk what, or maybe it's the antivirus checking every I/O, 🤷