Failed to fork child process: No such file or directory

[mark-8]

Hi,

This is related to #440.

I have the same issue and the following notes

• This is a default install with no options changed
• Git version is 2.6.4
• On a clean install of Windows 10 (with all available updates installed)
• There is no AV/Firewall blocking install - literally it's Windows 10 then Git
• There is no mintty.exe file in the bin folder (I think I should expect to see this?)
• This is a 64-bit install, default install path is Program Files - not Program Files (x86)
• git-bash.exe produces this error, as does using the right-click context menus
• git-cmd.exe seems to work ok
• git-gui.exe seems to work ok
• bash.exe in bin seems to work ok

If you need any other information please let me know.

[kostix]

No, mintty.exe should be under %ProgramFiles%\Git\usr\bin -- could you verify it?

[mark-8]

Yes, it is there. Opening it causes the same error.

[kostix]

@intared, any chance of trying to run it with procmon active to see what mintty.exe tried to open (and failed)?

[mark-8]

There's nearly 800 entries for it. Mostly with a result of "Success", some "Name not found", "Reparse" and "File Locked with only readers".

I think the culprit is three lines, each very similar, with an operation of CreateFile on the paths.

• %SystemDrive%\Users\username\RelaunchCommand=C\Program Files\Git\git-bash.exe
• %SystemDrive%\Users\username\RelaunchCommand=C\Program Files\Git
• %SystemDrive%\Users\username\RelaunchCommand=C\Program Files

They return "PATH NOT FOUND". The paths seem malformed in RelaunchCommand (I altered the paths before that).

Outside of that there is are the following lines.

• "Access Denied" on \Git\mingw64\share\git\git-for-windows.ico.
• "End of File" on \Git\etc\nsswitch.conf"

[edsondias]

Same issue here, only way to run bash is "Run as administrator"

[mark-8]

OK, to confirm, if I set git-bash.exe to run as administrator, it does work. Of course, I get the UAC prompt.

This wasn't an issue in the previous version I used (which I'm now kicking myself for not recording the version number of...).

[dscho]

The paths seem malformed in RelaunchCommand (I altered the paths before that).

Well, now I cannot know what the culprit is.

It has possibly something to do with this line.

[dscho]

Okay, I could not reproduce the exact issue, but I could verify via ProcMon that mintty.exe indeed tries to create a bogus file. The reason is that our patches did not make it upstream unharmed, and when MSys2 started shipping a newer version, the RelaunchCommand support we expected is no longer there, at least not in the form we wanted. Bummer.

[mark-8]

The paths seem malformed in RelaunchCommand (I altered the paths before that).

Well, now I cannot know what the culprit is.

The only altering I did here was to swap my username and drive letter to be generic.

Please let me know if you need any further information to help with this.

[mintty]

@dscho:

patches did not make it upstream unharmed

I do not think this is true. It's true they didn't make it unchanged, for reasons I explained and we discussed in length. The suggested feature is fully included in the current release, just using other option names. If you claim there is any harm in the implemented feature, please demonstrate it. If you simply think they should have been accepted in the exact form you wanted, I can't help it. And if that even makes you feel "bummer", you should take some relaxing Christmas holidays, please.

For the actual issue, see mintty/mintty#493. It's a Windows bug for which cygwin has a workaround (not yet released). For Git you'll likely have to achieve a similar workaround in MSys.

[dscho]

The suggested feature is fully included in the current release, just using other option names.

Which ones?

I feel that the evolution from my original patch to whatever patch you actually applied to implement the feature is woefully underdocumented, as is the exact difference how to use the feature. That is what is highly frustrating. I had plenty of time to work on this for over a month, and nothing happened back then. That is even further frustrating, and you can either acknowledge that or ignore it.

[dscho]

For the actual issue, see mintty/mintty#493.

That is not the bug that is discussed here. It is a different issue that should have been addressed by our upgrade to the new MSys2 runtime, as far as Git for Windows is concerned anyways.

[mintty]

About your request for the current status, see mintty/mintty#471 (comment) (of 3. Nov!):

Released in 2.2.1.

And the feature is fully documented in the manual page, including a full example.

---

I had plenty of time to work on this for over a month, and nothing happened back then.

This is an unfair statement, and it's nonsense, see mintty/mintty#471 (comment):

I guess you agree that the involved Windows feature is a very obscure and also poorly documented one. After you worked a month on a working patch, you should accept that I needed a month too to understand the issue, ponder alternatives (as the suggested solution isn't really nice due to its irreversible nature) and test everything. And as you are involved in open source yourself you should also be aware that this month had to be distributed over some time. If you would raise an issue of similar weirdness with, say, MS, what response time would you expect, honestly?

[dscho]

I think the culprit is three lines, each very similar, with an operation of CreateFile on the paths.

%SystemDrive%\Users\username\RelaunchCommand=C\Program Files\Git\git-bash.exe
%SystemDrive%\Users\username\RelaunchCommand=C\Program Files\Git
%SystemDrive%\Users\username\RelaunchCommand=C\Program Files

@intared actually, I can confim that this is not the culprit, as these lines appear even if everything works alright with starting Git Bash.

Any chance you can make the full log available?

[mark-8]

@dscho here you go.

Produced running git-bash.exe (not as administrator) in 2.7.0.

Logfile.zip

[dscho]

I fail to find anything of interest in the short amount of time I can afford to spend on this ticket today. However, you may want to download https://dl.bintray.com/git-for-windows/pacman/x86_64/:msys2-runtime-2.3.1.33884.84870b7-1-x86_64.pkg.tar.xz and extract msys-2.0.dll from it, overwriting the existing one in usr\bin, and test again, to make sure that a recent update did not incidentally fix it.

[dscho]

So I got the very same problem, also with mintty.exe (but not with bash -l -i in a cmd window). It appears only because I have tampered with /etc/nsswitch.conf (I removed the db item from the passwd: ... line).

The tell-tale is that running bash -l -i in a cmd window will show a prompt starting with Unknown+User@... and that calling strace -o log.txt ./mintty in usr\bin will produce a log.txt containing lines similar to these:

...
   77 7496631 [main] mintty 28236 pwdgrp::fetch_account_from_windows: line: <Unknown+User:*:4294967295:4294967295:U-Unknown\User,S-1-99-0:/:/sbin/nologin>
   39 7496670 [main] mintty 28236 pwdgrp::fetch_account_from_windows: line: <Unknown+Group:S-1-99-0:4294967295:>
   34 7496704 [main] mintty 28236 set_posix_access: ACL-Size: 112
 1048 7497752 [main] mintty 28236 set_posix_access: Created SD-Size: 156
   47 7497799 [main] mintty 28236 tty::get_event: couldn't create cygtty.input.avail.0
   22 7497821 [main] mintty 28236 __set_errno: void* tty::get_event(const char*, PSECURITY_ATTRIBUTES, BOOL):255 setting errno 2
   21 7497842 [main] mintty 28236 seterrno_from_win_error: C:/git-sdk-32/usr/src/MSYS2-packages/msys2-runtime/src/msys2-runtime/winsup/cygwin/fhandler_tty.cc:1838 windows error 1307
   22 7497864 [main] mintty 28236 geterrno_from_win_error: unknown windows error 1307, setting errno to 13
   44 7497908 [main] mintty 28236 fhandler_pty_master::setup: pty0 open failed - failed to create cygtty.input.avail
   77 7497985 [main] mintty 28236 __set_errno: fhandler_base* build_fh_pc(path_conv&):641 setting errno 6
   30 7498015 [main] mintty 28236 build_fh_pc: fh 0x0, dev 00000000
   33 7498048 [main] mintty 28236 open: -1 = open(/dev/ptmx, 0x8002), errno 6
...

Seeing as this is caused by tampering with the /etc/nsswitch.conf file, I would consider this a user-made problem rather than a bug in Git for Windows.

[vcx]

Same error here. But I think I found something useful to this discussion:

1. git-bash works with a different profile, from a different user (local or domain user) in the same machine. I'm seriously considering killing my profile just to confirm that git will work again with this method. With this, we can securely narrow down the root cause to either c:\users\username* or in registry below HKCU. This must be caused by a file there or a registry key, but the problem is isolated to my user.

2. differently from @intared, mu git-gui isn't working

3. git-bash works when running as admin (via right-click, run as administrator).\

4. I've checked with ACT's Compatibility Administrator to ensure that no compatibility fix or compatibility layer was being applied to git executables. I've also checked VirtualStore folder inside my profile dir or VirtualStore key in HKCU\software\classes and found nothing special related to git in both places.

All computers in my network that upgraded to 2.7.0 show the behavior above. I'm recommending my devs to stay with their current versions.

[dscho]

All computers in my network that upgraded to 2.7.0 show the behavior above.

Which was the last working version?

[dscho]

@intared @edsondias @vcx are you running this on domain-joined machines, maybe?

And: could y'all maybe spend some serious time trying to figure out using ProcMon what file was not found?

[vcx]

@dscho No domain joined machine. However, all of mine are Azure AD joined (if you're concerned with GPOs, AAD doesn't have them, and it's policies are less intrusive, such as password and device encryption only).

I've already dig into procmon. Nothing special there, except:

git-bash.exe (the original exe that the start menu points) triggers a ProcessCreate with the following path:

usr\bin\mintty.exe -o AppID=GitForWindows.Bash -o RelaunchCommand="C:\Program Files\Git\git-bash.exe" -o RelaunchDisplayName="Git Bash" -i /mingw64/share/git/git-for-windows.ico /usr/bin/bash --login -i

typing this exact command in CMD/Run/TaskManager fails 100% of time. Removing parameters one by one shows that even usr\bin\mintty.exe alone can trigger the same error, same message.

I've also compared procmon logs both trying to run the command as admin and as my regular user. Surprisingly, I found no big differences in file operations. And there's no significant file missing. One of them took my attention: an Access Denied while trying to set attributes in git-for-windows.ico. However, giving write permissions to the file, folder, upper folder and upper upper folder was enough to get rid of the Access Denied, but didn't change the initial problem of mintty.

In registry operations, the log on "as admin" scenario has twice more reads when trying to load COM dlls (mostly because when running as admin it tries to read also keys on HKCU\Software\Classes instead of only HKCR\classes). I'm not sure if this behavior is expected... but probably it isn't related to the problem we're talking about here. Process-level operations are almost equal, of course, until it breaks.

Logger.exe fails to attach in mintty. My next try will be on windbg looking for first chance exceptions.

[vcx]

I also did the same strace command. I don't know how to interpret it (I'm good with Windows internals, but not Linux/Unix) but I assume the same troubleshooting rules applies. Reading backwards, I think I found some suspects in the following lines. It's something related to path translation.

   48   23112 [main] mintty 11700 close: 0 = close(0)
--- Process 11700 loaded C:\Windows\System32\uxtheme.dll at 00007FFCEC550000
--- Process 11700 loaded C:\Windows\System32\msctf.dll at 00007FFCF0440000
--- Process 11700 loaded C:\Program Files\Common Files\microsoft shared\ink\tiptsf.dll at 00007FFCD4D00000
--- Process 11700 loaded C:\Windows\System32\oleaut32.dll at 00007FFCF10C0000
--- Process 11700 thread 5012 created
--- Process 11700 loaded C:\Windows\System32\clbcatq.dll at 00007FFCF0E10000
13116   36228 [unknown (0x1394)] mintty 11700 _cygtls::remove: wait 4294967295
--- Process 11700 thread 5012 exited with status 0x0
--- Process 11700 thread 14216 created
--- Process 11700 thread 15212 created
--- Process 11700 thread 4492 created
--- Process 11700 loaded C:\Windows\System32\DataExchange.dll at 00007FFCD3F10000
--- Process 11700 loaded C:\Windows\System32\dcomp.dll at 00007FFCEB5A0000
--- Process 11700 loaded C:\Windows\System32\d3d11.dll at 00007FFCEAFE0000
--- Process 11700 loaded C:\Windows\System32\dxgi.dll at 00007FFCEAF30000
--- Process 11700 loaded C:\Windows\System32\twinapi.appcore.dll at 00007FFCEC6F0000
 4361   40589 [main] mintty 11700 void: 0x0 = signal (1, 0x1)
   51   40640 [main] mintty 11700 void: 0x0 = signal (2, 0x100405670)
   24   40664 [main] mintty 11700 void: 0x0 = signal (15, 0x100405670)
   20   40684 [main] mintty 11700 void: 0x0 = signal (3, 0x100405670)
   21   40705 [main] mintty 11700 open: open(/dev/ptmx, 0x8002)
   20   40725 [main] mintty 11700 normalize_posix_path: src /dev/ptmx
   19   40744 [main] mintty 11700 normalize_posix_path: /dev/ptmx = normalize_posix_path (/dev/ptmx)
   19   40763 [main] mintty 11700 mount_info::conv_to_win32_path: conv_to_win32_path (/dev/ptmx)
   30   40793 [main] mintty 11700 mount_info::conv_to_win32_path: win32_device_name (/dev/ptmx)
   19   40812 [main] mintty 11700 mount_info::conv_to_win32_path: src_path /dev/ptmx, dst /dev/ptmx, flags 0x2, rc 0
   30   40842 [main] mintty 11700 fhandler_pipe::create: name \\.\pipe\msys-1888ae32e00d56aa-pty0-from-master, size 131072, mode PIPE_TYPE_MESSAGE
   68   40910 [main] mintty 11700 fhandler_pipe::create: pipe read handle 0x34C
   31   40941 [main] mintty 11700 fhandler_pipe::create: CreateFile: name \\.\pipe\msys-1888ae32e00d56aa-pty0-from-master
   38   40979 [main] mintty 11700 fhandler_pipe::create: pipe write handle 0x350
   25   41004 [main] mintty 11700 tty_list::allocate: pty0 allocated
   30   41034 [main] mintty 11700 fhandler_pipe::create: name \\.\pipe\msys-1888ae32e00d56aa-pty0-to-master, size 131072, mode PIPE_TYPE_MESSAGE
   45   41079 [main] mintty 11700 fhandler_pipe::create: pipe read handle 0x354
   25   41104 [main] mintty 11700 fhandler_pipe::create: CreateFile: name \\.\pipe\msys-1888ae32e00d56aa-pty0-to-master
   34   41138 [main] mintty 11700 fhandler_pipe::create: pipe write handle 0x358
   24   41162 [main] mintty 11700 fhandler_pipe::create: name \\.\pipe\msys-1888ae32e00d56aa-pty0-to-master-cyg, size 131072, mode PIPE_TYPE_MESSAGE
   41   41203 [main] mintty 11700 fhandler_pipe::create: pipe read handle 0x35C
   24   41227 [main] mintty 11700 fhandler_pipe::create: CreateFile: name \\.\pipe\msys-1888ae32e00d56aa-pty0-to-master-cyg
   33   41260 [main] mintty 11700 fhandler_pipe::create: pipe write handle 0x360
   32   41292 [main] mintty 11700 fhandler_pipe::create: name \\.\pipe\msys-1888ae32e00d56aa-pty0-echoloop, size 131072, mode PIPE_TYPE_MESSAGE
   38   41330 [main] mintty 11700 fhandler_pipe::create: pipe read handle 0x364
   22   41352 [main] mintty 11700 fhandler_pipe::create: CreateFile: name \\.\pipe\msys-1888ae32e00d56aa-pty0-echoloop
   31   41383 [main] mintty 11700 fhandler_pipe::create: pipe write handle 0x368
   49   41432 [main] mintty 11700 mount_info::conv_to_posix_path: conv_to_posix_path (C:\Users\username, 0x0, no-add-slash)
   41   41473 [main] mintty 11700 normalize_win32_path: C:\Users\username = normalize_win32_path (C:\Users\username)
   30   41503 [main] mintty 11700 mount_info::conv_to_posix_path:  mount[0] .. checking / -> C:\Program Files\Git 
   27   41530 [main] mintty 11700 mount_info::conv_to_posix_path:  mount[1] .. checking /bin -> C:\Program Files\Git\usr\bin 
   19   41549 [main] mintty 11700 mount_info::conv_to_posix_path:  mount[2] .. checking /tmp -> C:\Users\username\AppData\Local\Temp 
   21   41570 [main] mintty 11700 mount_info::conv_to_posix_path: /c/Users/username = conv_to_posix_path (C:\Users\username)
   53   41623 [main] mintty 11700 pwdgrp::fetch_account_from_windows: line: <Unknown+Group:S-1-99-0:4294967295:>
   32   41655 [main] mintty 11700 set_posix_access: ACL-Size: 112
   38   41693 [main] mintty 11700 set_posix_access: Created SD-Size: 156
   34   41727 [main] mintty 11700 tty::get_event: couldn't create cygtty.input.avail.0
   22   41749 [main] mintty 11700 __set_errno: void* tty::get_event(const char*, PSECURITY_ATTRIBUTES, BOOL):255 setting errno 2
   23   41772 [main] mintty 11700 seterrno_from_win_error: C:/git-sdk-64/usr/src/MSYS2-packages/msys2-runtime/src/msys2-runtime/winsup/cygwin/fhandler_tty.cc:1838 windows error 1307
   65   41837 [main] mintty 11700 geterrno_from_win_error: unknown windows error 1307, setting errno to 13
   56   41893 [main] mintty 11700 fhandler_pty_master::setup: pty0 open failed - failed to create cygtty.input.avail
  120   42013 [main] mintty 11700 __set_errno: fhandler_base* build_fh_pc(path_conv&):641 setting errno 6
   45   42058 [main] mintty 11700 build_fh_pc: fh 0x0, dev 00000000
   28   42086 [main] mintty 11700 open: -1 = open(/dev/ptmx, 0x8002), errno 6
   24   42110 [main] mintty 11700 __set_errno: int openpty(int*, int*, char*, const termios*, const winsize*):138 setting errno 2
  124   42234 [main] mintty 11700 open: open(/dev/windows, 0x0)
   30   42264 [main] mintty 11700 normalize_posix_path: src /dev/windows
   25   42289 [main] mintty 11700 normalize_posix_path: /dev/windows = normalize_posix_path (/dev/windows)
   24   42313 [main] mintty 11700 mount_info::conv_to_win32_path: conv_to_win32_path (/dev/windows)
   28   42341 [main] mintty 11700 mount_info::conv_to_win32_path: win32_device_name (/dev/windows)
   64   42405 [main] mintty 11700 mount_info::conv_to_win32_path: src_path /dev/windows, dst \Device\Null, flags 0x2, rc 0
   31   42436 [main] mintty 11700 build_fh_pc: fh 0x1803288F8, dev 000D00FF
   59   42495 [main] mintty 11700 fhandler_base::open: (\Device\Null, 0x10000)
   32   42527 [main] mintty 11700 fhandler_base::set_flags: flags 0x10000, supplied_bin 0x10000
   61   42588 [main] mintty 11700 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x10000
   27   42615 [main] mintty 11700 fhandler_base::set_flags: filemode set to binary
   24   42639 [main] mintty 11700 fhandler_base::open: 0x0 = NtCreateFile (0x368, 0x80100000, \Device\Null, io, NULL, 0x0, 0x7, 0x1, 0x4020, NULL, 0)
   24   42663 [main] mintty 11700 fhandler_base::open: 1 = fhandler_base::open(\Device\Null, 0x10000)
   25   42688 [main] mintty 11700 open: 0 = open(/dev/windows, 0x0)
--- Process 11700 loaded C:\Windows\System32\UIAutomationCore.dll at 00007FFCDB4C0000
--- Process 11700 loaded C:\Windows\System32\userenv.dll at 00007FFCED540000
--- Process 11700 thread 9368 created
--- Process 11700 loaded C:\Windows\System32\sxs.dll at 00007FFCEDC10000
--- Process 11700 loaded C:\Windows\System32\oleacc.dll at 00007FFCD4780000
--- Process 11700 loaded C:\Windows\System32\twinapi.dll at 00007FFCD4E50000
53362   96050 [main] mintty 11700 cygwin_select: select(1, 0xFFFFC580, 0x0, 0x0, 0x0)
   92   96142 [main] mintty 11700 cygwin_select: to NULL, ms FFFFFFFF
   96   96238 [main] mintty 11700 dtable::select_read: /dev/windows fd 0
   69   96307 [main] mintty 11700 select: sel.always_ready 0
   50   96357 [main] mintty 11700 select_stuff::wait: m 2, ms 4294967295
 3488   99845 [main] mintty 11700 select_stuff::wait: wait_ret 2, m = 2.  verifying

[keithjjones]

👍 here too

Fresh Windows 10 machine, Enterprise, on the MS Azure domain.

[JamesXNelson]

For what it's worth, I am on a fresh windows 8, and git bash was working fine, until I closed all running instances, and restarted.

I had recently been installing things and updating the PATH with various instances of git bash open, including installing both python 3 and 2 (and having one of them on my user PATH, and the other on system PATH). In between restarting all instances, I also tried removing the python version I didn't want (for the code I need to build), so I wound up just clearing my user PATH, as it had nothing of use that wasn't already in global PATH.

Hope these tidbits help!

[mintty]

I suggest git bash should update to mintty 2.2.4. It contains improvements both in startup and startup error reporting.
The command quoted by vcx in #580 (comment) would be changed to usr\bin\mintty.exe -o AppID=GitForWindows.Bash -o AppLaunchCommand="C:\Program Files\Git\git-bash.exe" -o AppName="Git Bash" --store-taskbar-properties -i /mingw64/share/git/git-for-windows.ico /usr/bin/bash --login -i.

[dscho]

I will upgrade once I can afford the time to re-test and re-patch our version of mintty.

[mintty]

The latest version is 2.3.3 now. For taskbar integration, there should be no patches necessary anymore.
If there are any other patches, I will gladly consider their upstream integration so Git can integrate mintty patch-free.

[keithjjones]

If Git bash updates, let me know and I'll be happy to test it.

[nilzona]

I had this problem on git bash v2.6.2, Windows 10. I restarted the computer and everything was back to normal. ... I had a flashback to Windows 95

[mbp]

I just updated to latest Git for Windows which ships with mintty 2.4.2. The error message is no longer Failed to fork child process: No such file or directory, but is now: Error: could not fork child process: There are no available terminals (-1)..

[mintty]

This error information pins the issue more precisely to the forkpty() system call of cygwin/msys.

[mbp]

Well then it doesn't seem to be a git-for-windows issue. Where should this be reported? https://github.com/Alexpux/MSYS2-packages/issues?

[mintty]

See also https://www.cygwin.com/faq.html#faq.using.fixing-fork-failures.

[dscho]

See also https://www.cygwin.com/faq.html#faq.using.fixing-fork-failures.

Given that the most likely location where that ENOENT is set is in openpty(), I seriously doubt that this FAQ would help.

The more likely culprit is that the current account is not known to Cygwin and it mixes up the permissions when trying to access the (emulated) /dev/ptmx.

[mintty]

/dev/ptmx reminds me of an "Azure" account issue (also mentioned above) that has recently been fixed (or rather worked-around) in cygwin. So maybe an update to cygwin 2.6.0 helps? Just speculating.

[dscho]

bash: warning: setlocale: LC_ALL: cannot change locale (enu): No such file or directory
0 [main] bash 8000 fork: child 7612 - died waiting for dll loading, errno 11

@SnehaRane1987 can you verify that your LC_ALL environment variable is not set to enu? That value is invalid for MSYS2. You would have to override it, e.g. to C.

[dscho]

@mbp would you please download https://github.com/git-for-windows/msys2-runtime/releases/download/snapshot-2016-07-09/msys-2.0.dll and drop it into \usr\bin (overwriting the existing msys-2.0.dll) and try again?

[mbp]

@dscho it works!

[mweinand]

Works for me too! Thank you!

[JBlond]

That DLL solves also the issue with Azure AD
Starting the Git bash with that I get
AzureAD+Jblond@workstation:~$

[mark-8]

The new DLL works for me. Thank you.

[dscho]

Thank you all for testing! I just built fixed 32-bit and 64-bit msys2-runtime packages and uploaded them to the Pacman repository of Git for Windows' SDK.

Meaning: the next Git for Windows release will have the fix.

[dscho]

For everybody who cannot wait for the next official release, here Is a prerelease with the fix: https://github.com/git-for-windows/git/releases/tag/prerelease-v2.10.0.windows.1.11.geda474c

[dscho]

Oh, and: If y'all could test the prerelease and report whether it fixes the issue, that would be grand!

[mbp]

@dscho I can confirm that the prerelease also works :-)

[JBlond]

@dscho the prerelease works!

[sudosean]

Hi all,

My git commands are failing with this error as well:

    0 [main] sh 15752 fork: child 16064 - died waiting for dll loading, errno 11
/mingw64/libexec/git-core/git-sh-setup: fork: retry: No child processes
1160649 [main] sh 15752 fork: child 9068 - died waiting for dll loading, errno 11
/mingw64/libexec/git-core/git-sh-setup: fork: retry: No child processes
3320634 [main] sh 15752 fork: child 636 - died waiting for dll loading, errno 11
/mingw64/libexec/git-core/git-sh-setup: fork: retry: No child processes
7464059 [main] sh 15752 fork: child 14768 - died waiting for dll loading, errno 11
/mingw64/libexec/git-core/git-sh-setup: fork: retry: No child processes
15644515 [main] sh 15752 fork: child 1808 - died waiting for dll loading, errno 11
/mingw64/libexec/git-core/git-sh-setup: fork: Resource temporarily unavailable

• I am on windows 10
• git for windows version is 2.10.1 64 bit
• I've also tried the pre-release in this thread
• I've tried multiple different setup options including using mintty and the command prompt with the same error each time I start the git bash.
• I've tried on a few different networks
• Same errors in powershell

Strange thing is, I can run basic git commands like 'status', 'pull' , 'push', 'checkout'

But when I run git rebase -i branch_name it runs that same error again.

Is there anything else I can provide to help debug this?

Thank you kindly!

[StevenByks]

Are there any open issues for this bug? I run into this intermittently. I almost posted here a week ago when I ran into this, but then the issue mysteriously resolved itself about 30-45 minutes later. Well today I ran into this again, but this time I discovered something interesting. So I was getting the error "Failed to fork child process: No such file or directory", and I thought I would just keep working until it resolved itself. Well then I ran into another seemingly unrelated issue. I was trying to delete a directory containing a git repo I had previously been working on, but some process had a lock on a random file in the .git folder. I used ProcessExplorer to search for the offending process, and it was "sh.exe" from git bash. But here's the really interesting thing. I didn't have any git bash windows open at the time, and the process showed up as "suspended". Like it was just permanently not actually running on the cpu. As soon as I killed the suspended "sh.exe" process I was able to open a new git bash window without getting the error (and I could delete those files).

[PhilipOakley]

Are there any open issues for this bug? I run into this intermittently. I almost posted here a week ago when I ran into this, but then the issue mysteriously resolved itself about 30-45 minutes later.

Opening a fresh isssue, with a back reference here, but with all the important background info (versions..) the template asks for would help if the issue is sufficiently distinct.

Well today I ran into this again, but this time I discovered something interesting. So I was getting the error "Failed to fork child process: No such file or directory", and I thought I would just keep working until it resolved itself.

What were the activities that you'd been performing on that repo, both using `git` commands and windows actions (inc. editors and other long run processes that may have file handles open - which are implicit locks..)

Well then I ran into another seemingly unrelated issue. I was trying to delete a directory containing a git repo I had previously been working on, but some process had a lock on a random file in the .git folder.

How 'random'? Did you catch it's name? or an indication of it's name (e.g. `.pack`, `.idx`, ALLCAPS name) etc.?

I used ProcessExplorer to search for the offending process, and it was "sh.exe" from git bash. But here's the really interesting thing. I didn't have any git bash windows open at the time, and the process showed up as "suspended". Like it was just permanently not actually running on the cpu. As soon as I killed the suspended "sh.exe" process I was able to open a new git bash window without getting the error (and I could delete those files).

Any more information you can garner next time on such a sh.exe would be an advantage. Git often spawns excess shells which do linuxy tasks with poor abstractions for windows... They just need hunting down!

[dscho]

But here's the really interesting thing. I didn't have any git bash windows open at the time, and the process showed up as "suspended". Like it was just permanently not actually running on the cpu. As soon as I killed the suspended "sh.exe" process I was able to open a new git bash window without getting the error (and I could delete those files).

That's an interesting tidbit. I wonder how many other MSYS2 runtime issues have that very same root cause...