Error: could not fork child process: Resource temporarily unavailable (-1)

[rinyre]

Hello! I'm getting the following when I attempt to start the process:

Error: could not fork child process: Resource temporarily unavailable (-1).
DLL rebasing may be required. See 'rebaseall / rebase --help'.

Obviously there is no rebase binary packaged with this like Cygwin would typically have. Is there another way to rebase this?

[mintty]

Did you install from the release package (installer) or did you build yourself?
If you built yourself, what's the output of uname -a?

[rinyre]

I downloaded a release package. However, rebooting fixed the issue for me
for now, but I imagine I may run into that in the future.

On Sep 30, 2016 1:56 AM, "mintty" notifications@github.com wrote:

Did you install from the release package (installer) or did you build
yourself?
If you built yourself, what's the output of uname -a?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#6 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB1yiPliU32JOIkNAAWNvXNJiI10KAAMks5qvLKagaJpZM4KKkOP
.

[mintty]

According to common wisdom, any Windows system should be rebooted at least every 42 days, anyway:)

[wtchappell]

I just got hit with this immediately after a reboot - I installed using the installer.

[mintty]

Unfortunately, cygwin has always had occasional problems with forking, see https://cygwin.com/faq.html#faq.using.fixing-fork-failures
This seems to be occuring more often with current builds of the Windows Technical Preview release (or even much more often with one specific build).
It's not a mintty issue.

[adam42a]

I am getting it all the time when I launch cygwin from a Windows taskbar launcher with mintty.exe - (the default launcher created by the cygwin installation).

But I can double-click mintty.exe in the File Explorer or launch from cmd, and cygwin runs happily, or I can run it as administrator.

Windows 10 is obviously doing some shenanigans with the taskbar.

[mintty]

Is this Cygwin 64- or 32-bit? With taskbar launcher you mean an application icon docked to the taskbar?

[adam42a]

64-bit. Yes - an application icon pinned to the taskbar.

[mintty]

Cannot reproduce, works here. Have you tried "rebasing"? Can you try with a fresh (parallel, minimal) Cygwin installation?

[adam42a]

Problem gone away now. Typical Windows.

[pequalsmp]

For those passing from Google - Encountered the same problem with a new (correct me if im wrong) feature in Windows 10:

Force randomization for images (Mandatory ASLR)
Force relocation of images not compiled with /DYNAMICBASE

Turning it off (as its by default) resolves the problem.

[mintty]

Thanks for this information. We should share it on the cygwin mailining list.
Is this with Cygwin 64 Bit?
Can you provide details about how to turn off that Windows feature?

[pequalsmp]

Sure.

I'm using Cygwin x64 on Windows 10 build 1709.

To disable this feature you'll have to:

• Press Win + S
• Type in Windows Defender Security Center
• Click App & browser control
• Scroll down and click Exploit protection settings
• Find the Force randomization for images section and select Off by default
• Reboot

It should be off by default, but i think Microsoft will switch that on by default in the future as more and more programs become compatible.

[embray]

Has this been brought up on the Cygwin mailing list yet? I don't see any reference to it but I wanted to make sure. This is actually pretty severe problem IMO.

[mintty]

No, I had the intention to report it but you are welcome to do it yourself, please.
I agree this sounds like important to be discussed there.

[embray]

Will do, thanks.

[Structed]

I've just encountered this issue. However, Force randomization of for images (Mandatory ASLR) was already set to Off by default. Also, rebooting did not solve the problem.

[embray]

There's also a "randomize memory allocations (Bottom-up ASLR) that I suspect might be a problem for Cygwin's fork, but I'm not sure.

[gamitech]

Here is the fix.
1 Go to you Windows Defender Security Center settings
2 Click on App & Browser Control
3 At the bottom click on the "Exploit Protection Settings" link
4 Go to "Program Settings" and click on the "Add program to customize" -> "Choose exact file path"
5 Navigate to "C:\Program Files\Git\usr\bin\sh.exe" and add it
6 Override and turn off the following:
Mandatory ASLR
Randomize memory allocations (Bottom-up ASLR)
7 Click "Apply" and now everything should work fine.

Also add these other binaries from the same folder: expr.exe, uname.exe, grep.exe, rm.exe

Good luck,
Gabriel

[acinnes]

I just hit this issue today trying to launch WSL Terminal on Windows 10 (build 17134.228), and then found it affected Git Bash and msys2 as well. However changing the ASLR settings for just mintty.exe or bash.exe wasn't enough. I found I also had to change them for wslbridge.exe, in the case of WSL Terminal, and other files in the case of Git Bash and msys2.

If you have msys2 installed, you can user PowerShell (in Admin mode) to script the changes for all of the binaries as follows:

$files = Get-ChildItem C:\msys64\usr\bin*.exe
$files | ForEach-Object {Set-ProcessMitigation -name $_.fullname -disable ForceRelocateImages, BottomUp, HighEntropy}

With Git for Windows, do the same but change the line for setting $files as follows:

$files = Get-ChildItem -recurse "C:\Program Files\Git*.exe"

Note that this may be disabling the ASLR settings for more binaries than strictly necessary; I'm not sure which aspects of the msys2/cygwin runtime are affected by ASLR.

[TheBestF22]

@acinnes

For Future Reference:

That code can be even more Simplified/Shortened to something like this:

$files = (Get-ChildItem 'C:\msys64\usr\bin\*.exe').FullName
$files.ForEach({Set-ProcessMitigation $_ -Disable ForceRelocateImages})

And for Git (for Windows), to something like this:

$files = (Get-ChildItem 'C:\Program Files\Git\usr\bin\*.exe').FullName
$files.ForEach({Set-ProcessMitigation $_ -Disable ForceRelocateImages})

IMPORTANT NOTES (for consideration):

• This will NEVER be needed for non-64-bit versions of Windows (but who is still using 32-bit Windows, right?...)
• It's ONLY necessary for 64-bit versions of Windows 10 (or Windows 7/8/8.1 with a recent EMET) that has the Force randomization for images (Mandatory ASLR) option in the On by default System-Wide Setting (Or something Equivalent by other Security Suite's Vendors)
• ForceRelocateImage (AKA "Mandatory ASLR") is the only Mitigation that has to be explicitly -Disabled --> Without this Mitigation, ASLR will NOT be Enforced since the Applications don't "request" it (like the ones prepared for it do) --> Without ASLR, the other Mitigations @acinnes -Disabled there - BottomUp,HighEntropy - aren't necessary since they're NOT "applicable" since they're ASLR-Enhancing (further in-depth) Mitigations.

I'll include a "ScreenShot" of the "System Settings" Tab of the "Exploit Protection" Section of the "Windows Security Center" System App (Windows 10 x64 - Version 1803 - Build 17134.228 - Full Build/Version Name 17134.rs4_release.180410-1804) just for good measure - though it also explains a bit about these settings --> if it has "ASLR" in the Mitigation Name, it won't apply if there's NO "ASLR" applied to a Process/Application/Executable.

Cheers.

EDIT

Here's some

• Handy,
• Handmade,
• Brand-New,
• "Double-Click"able,
• Step-by-Step Self-Explained/Documented
  PowerShell Script Files!.

Just make sure the "$installPath" variable (near the top of the Script) Points to the "Right Path" and Change the extension by removing the ".txt" at the end... (should be ".ps1" after that...)

MSys64 - Default Path .ps1.txt
Git for Windows 64-Bit - Default Path .ps1.txt

Bye then.

[TheBestF22]

@gamitech

While not a bad attempt...

With the Latest Versions of both Windows (Upgrades + Updates) and Git (for Windows) (which obviously includes an Updated MSys2/MinTTY), if the System-Wide Setting of Mandatory ASLR is in the On by default Option (for Security reasons, etc.), it's "more the exception than the rule":

• it's rare the executable in the C:\Program Files\Git\usr\bin\ Path/Folder that doesn't need to be added to the "Exceptions List" and the "Windows Security Center" App is just awful/dreadful to add 200+ ".exe"s and change the Mitigations Overrides, one by one...

(apparently this "Bug" has something to do with with direct references/accesses to msys-2.0.dll's "Image-based entry point Memory Addresses" -- instead of the more Normalized and almost/mostly obligatory way of loading DLLs by way of the several "Windows API"s... Probably a side effect of some Cross-Compiling/Assembling/Linking Tools used in the process of "Porting" the code to Windows... And not really a problem unless those "Addresses" are "Randomised" -- as per what "ASLR", "Address Space Layout Randomisation", is ALL About after all...)

Example of a VERY SIMPLE ASLR with a Google Search Link:

(Note: in a good ASLR implementation EVERYTHING moves around, not just the `Code´...)

Cheers!.

[mintty]

Thanks for the additional information. Actually, I'm getting an error with this command:

+ $files.ForEach({Set-ProcessMitigation -Disable ForceRelocateImages})
+               ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Set-ProcessMitigation:String) [
   ], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Also, I'd prefer some generic description, to accomodate cygwin users too, like: cd /bin, then start powershell there (winpty powershell or cygstart powershell), $files = (Get-ChildItem '*.exe').FullName, and then, well, something that works. Also, it's a bit hard to test not being familiar with powershell; echo $files works but anything like $files.foreach({echo}) seems to be bogus...

[TheBestF22]

@mintty

Sorry about that!...

I guess I messed up something while Copying the Code from "PowerShell" to here...
(It was pretty late here) (and it is so, once again... -_-;; ... ) EDIT - it was around 5:30 a.m. around here...
I Edited that Comment to fix it --> it was missing the "$_" Parameter...
(relevant, and quite important, in that "String[].ForEach({})" method...)

(There's also the Remote Chance that the "ProcessMitigations" PowerShell "Module" is not present... And since it comes included with relevant Windows Versions, it would mean there's "Nothing to do Here" with "PowerShell" and it might be caused by similar Functionality on "Security Suites" from other Companies...)

About the rest You talked about:

Since I was Building on the Previous Comment to "Shorten" the Commands used and Remove Unnecessary Mitigations being Disabled as I explained there (and taking longer while doing so for each file), I didn't think about that there...

As for info for "cygwin" users...
The problem of this Issue (#6) is, normally, NOT being able to even Start the Terminal and instead Receive that dreaded "
Error: could not fork child process: Resource temporarily unavailable (-1).
DLL rebasing may be required. See 'rebaseall / rebase --help
" message...

BTW: (and just FYI)
I did not want to touch PowerShell with any kind of pole of any length before (too) Because it would mean I'd need to learn a "New" programming language...
I only did delve into "PowerShell" because there was no other Sane Way to Add ALL those ".exe"s to the Exploit Control and Define their Overrides! (It would be "MADNESS!!!" to Add One-by-One and Configure the it's Mitigation Override, also One-by-One...)
And from What I Learned of "PowerShell" in these last 2 Days (which, Note: it was a Whole LOT!) is a "Weird Mix" of Parts of the normal Windows CMD, Linux BASH and C# + .Net Core (a subsection of .Net Framework)!!!...
Specially, Scripting!.

I also Edited this in the Other Post but just so You see it directly on Your GutHub Notifications/Emails, I'll also Put these here:

MSys64 - Default Path .ps1.txt
Git for Windows 64-Bit - Default Path .ps1.txt

These are Automated "PowerShell Scripts" that can be "Double-Clicked"/Executed!. (one is just a slight variation of the other...)
They're pretty well Documented, from Both the Runtime Step-by-Step Warnings/Status Messages and "Pauses" to the Code Comments in there Explaining What the Code is Doing!. (Except in the "Admin Self-Elevation Prompt" Section of the Code -- Because it's just Hard to explain that part but Not that Difficult to Understand it...

By the Nature/Architecture of these "PowerShell Scripts", they can be Executed "ANYWHERE".
But thanks for Weird Limitations on this GitHub's Comment File Upload System, the ".txt" extension MUST First be Removed from the File Name so it ends in the ".ps1" Extension...
The Script needs a Variable ("$installPath") near the Top of the Script File to be Edited so it Points to the right "Root Installation Path".
The Rest is Automatic.

If it's Run in an already Elevated/Administrator PowerShell (Called by Whatever from Wherever), it will Execute Right Away with little to no Status Messages. (the "Set-ProcessMitigation" "cmdlet", as they call them, doesn't Print Anything unless it's Errors...)
If Not, It will Relaunch itself Asking for Permission Elevation to Admin (via the normal "Windows UAC Prompt") while, previously, telling the user it WILL DO SO and Warning the User to ALWAYS make sure of what They're letting through the "Windows UAC Prompts" and waiting for them to Read it and Acknowledge it before Proceeding into the Relaunch Proper... (by asking them to "Press Enter to Continue..." kind of stuff - Windows CMD "Pause" Style)
In any case, it will always wait for the user to "Press Enter" just before "Exiting" in the End so everything can be read, even if it was Originally Launched by a "Double-Click" (Normally, the Window Closes itself in these cases...)

These "PowerShell Scripts" should, Hopefully, Help Automate this Horrible Process of Bulk Adding Exploit Mitigation Rules/Exceptions...
(And maybe even create a "Template" for other Projects with Problematic Software Conflicts with Exploit Mitigations... Who knows?... )

For Further Automation, I guess the Script can be Stripped of the "Manually inserted Status Messages/Warnings" and "Pauses" ("Press Enter to Continue..." stuff) and, if Guaranteed to Always Run in an Admin Elevated Environment, it can also be stripped of the "Admin Self-Elevation Prompt" Section of the Script...

Anyway...
Just FYI:

• "powershell.exe" is better for Running the Script
• "powershell_ise.exe" is better for Editing the Script / Developing in "PowerShell"

I'm gonna see if I can get some 4 hours of Sleep or something now... DX
It's 7:20 a.m. NOW!...
I even Accidentally pressed SHIFT + ENTER and it Sent the Comment before it was Ready...
I've been Working on this "ALL Night Long"... **-_-**zZzZzZ
And it Shows!...

Best Regards from Portugal!. (it's not like I'm hiding it... It's Right There on My Profile...)

C Ya L8r then!. ;P

João Pedro Cunha
( AKA TheBest_F-22!. )

[user29387]

My PC was updated to Windows 10 version 1803 17134.254 over the weekend.

I'm using MSYS2, and immediately noticed that command-line interactions of this form have trouble:

$ script | cat

where 'script' can be as simple as:

#!/bin/bash
cat file

In other words, the script invokes a subprocess that produces standard output, which is then piped into another command. The error is a hang and eventually "fork: retry: Resource temporarily unavailable".

The shell where this problem occurs is one invoked directly from a desktop shortcut, like this:

s:\msys64\usr\bin\bash.exe --login -i -s 000

I haven't resolved the problem as yet, and so far have looked into issues like ASLR and randomization, rebasing, and so on. I don't have a clear picture of what the underlying issue is, and am reluctant to hack away.

[mintty]

In the latter case, mintty is not even involved (starting bash directly from a shortcut)! Even if it were, it would not be a mintty issue if it happens inside the shell.

[TheBestF22]

@mintty <https://github.com/mintty> Did my Last *Comment* (That GIANT *Wall-of-Text*) Help?... (I'm just curious/asking because I didn't see any reaction from You... Sorry about that...) I was quite tired and even sent it before I was finished because I (while half asleep) pressed *ENTER* before releasing the *SHIFT* Key... I then finished it and did many QC/QA related *EDIT*s/Corrections, some of questionable decision making processes (I was too sleepy), like stating the Hours when I started writing the Posts and when I finished it... Things like that... You should probably Notice that it is not the same as the e-mail/Notification You received before if You Read it *Directly* on The GitHub Issue's page... I should also Note that the *2 Lines* (now Corrected and Working) from my Inicial Comment is everything I need for personal use. (since "*I know what I'm doing*"...) I only wrote that more Complex and *Advanced Script* for "educational purposes" and so anyone could simply just "Double Click" a file, confirm the Admin Elevation Prompt (UAC) and simply be done with it and get everything to work... Maybe those 2 Lines could be added to Run during the last steps of the installation after a quick test and user informative prompt?... In my case, I was using "*Process Explorer*" while doing a new "*Git for Windows*" Upgrade and noticed that in the end, it runs some final set-up scripts in a tree of Linux-Original-processes (bash/ln/rm/MinTTY/ls/...) that keep Crashing and only after, when I actually tried to test/use it, did I find/come across this *Issue* (#6) (and did this "*fix*"/workaround) ... Anyways... What @user29387 said, while not being related with MinTTY, is probably the same problem - those */usr/bin* "*.exe*"s/binaries and Windows Exploit protection settings... This *issue* (#6) on GitHub just happens to be VERY *near the Top* (if not the very 1st entry - might vary with country) of *Google Search* for this "*Error Message*" (which is also in the Subject/Name of the issue itself) ... (He probably even has the MinTTY binary somewhere in the same folder...) (Probably a Good Way to test my Script?... - Though it needs that Manual Variable Edit...) *P.S.:* I'm writing *this* from an e-mail to test This GitHub's *reply-to* Functionality and see How it goes... (I may need to go to GitHub itself to make corrections to this if it doesn't come out as expected though... I'll see, I guess...) Bye then.

…

On Mon, Sep 10, 2018, 23:19 mintty ***@***.***> wrote: In the latter case, mintty is not even involved (starting bash directly from a shortcut)! Even if it were, it would not be a mintty issue if it happens inside the shell. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMf68mO5P8ybzQcy7nYG3rvZ1ZxVx94Sks5uZuVhgaJpZM4KKkOP> .

[mintty]

I appreciate your script and additional explanations, for anyone interested in the background. I do not have the capacity to study it fully myself right now. If you'd like to contribute further, the following would be great:

• (as I outlined in my previous response to you) a more generic script that can be started from either of cygwin, msys, git-for-windows, whereever installed
• as the command still does not run for me after the $_ fix, and Mandatory ASLR is disabled in my Windows, which might be related, some error handling in the script that handles this with a proper message
• maybe the ASLR configuration is available at the Windows API? If you find such information, somebody could make a small tool, to be independent from heavy-weight Powershell
• maybe you or me could then inform the cygwin mailing list about this solution

[user29387]

Since I posted a couple of days ago, I though I would do a followup, even though the issue doesn't seem connected with mintty.

I generated a couple of null C programs, with this code in each:

int main() {return 0;}

These are 'np1' and 'np2'.

I put the first in a script:

#!/bin/bash
np1
exit 0

and then run the script and the second program using a pipe:

script | np2

This sometimes works, but typically freezes, with a dramatic change with Windows 10 version 1803. The script and pipe seem to be required. The programs do no I/O, and thus the pipe is not actually used.

I tried a lot of things, including peflags/rebase, without any success. One thing that does seem to work is to run the top-level shell as an Administrator. I don't know why this works, but it should be a big hint to someone out there who is more astute than I in the workings of Cygwin and Msys.

The other approach that seems to work is to change the first line of the script to this:

##!/bin/bash

The extra '#' has the effect of making the first line into a comment, and thus the shell invokes a standard tool like /bin/bash or /bin/sh to interpret the script commands. This is conceptually similar to the '#!' notation, but presumably is processed in a somewhat different way.

[deebugz]

For anybody who arrives here after trying to install git for windows under Win10 amd64: I'm running all exploit protections plus full software restriction policies. There seems to be some bug in mingw64, and I had to explicitly add the path "C:\Program Files\Git*" to the SRP and set it to unrestricted. Perhaps the installer is using some nonstandard way of specifying file paths.

So, to install git without having to turn of exploit protections and reboot, first, do the install and it will fail after copying all (most?) of the files. Then run the above powershell scripts to disable aslr for the git binaries. Now install git again into the same folder, and it will say that it wasn't able to uninstall the previous installation. Continue, and after the install gets going installing files, you change "C:\Program Files\Git*" to "Unrestricted". That way, at the end of the installation process, git.exe will be able to do things like changing the default editor.

[RvBVakama]

Avast fix:
Go Avast interface -> settings -> general -> exclusions -> add your folder directory where your "git-bash.exe" lives.

[AnrDaemon]

For me, this was ADB shell daemon running after one command in terminal.

[jrmoserbaltimore]

What about fixing the application so it works with the exploit mitigations?

[mutageneral]

@jrmoserbaltimore

What about fixing the application so it works with the exploit mitigations?

The cygwin people talked about it in this thread : https://sourceware.org/pipermail/cygwin/2020-August/245973.html
Also, the git for windows people talked about implementing all git commands natively without using fork() and more : git-for-windows/git#1412 (comment)

Looking at these it seems like it is a very tough job to do, but we might get it one day.

[aarav2you]

You can just turn of ASLR for all the .exe in GitHub bin, run this script in powershell as admin. You must restart your PC after you have ran. Also replace X with the actual drive letter (probably C).

Get-Item -Path "X:\Program Files\Git\usr\bin*.exe" | %{ Set-ProcessMitigation -Name $_.Name -Disable ForceRelocateImages }

[mintty]

Thanks for the suggestion. My first impression was it would help, even without rebooting, but then I had a lot of trouble fiddling with these options, so I'd better not touch them again...

[Biswa96]

There is a recent discussion about it here https://cygwin.com/pipermail/cygwin/2021-February/247922.html. The solution is to disable ASLR option in binutils ld. The issue is only with fork() in cygwin based binaries. mingw toolchain is OK.

[rubenheymans]

Sure.

I'm using Cygwin x64 on Windows 10 build 1709.

To disable this feature you'll have to:

• Press Win + S
• Type in Windows Defender Security Center
• Click App & browser control
• Scroll down and click Exploit protection settings
• Find the Force randomization for images section and select Off by default
• Reboot

It should be off by default, but i think Microsoft will switch that on by default in the future as more and more programs become compatible.

I got this error when I lost power to my pc, this fixed it for some reason, thanks! So random

[vamshichintu]

Error: Could not fork child process: Resource temporarily unavailable (-1).
DLL rebasing may be required; see 'rebaseall / rebase --help

[Biswa96]

Try to reinstall wsltty and/or exclude wsltty install directory in antivirus scanning operation.

[iamABHIK123]

Sure.

I'm using Cygwin x64 on Windows 10 build 1709.

To disable this feature you'll have to:

• Press Win + S
• Type in Windows Defender Security Center
• Click App & browser control
• Scroll down and click Exploit protection settings
• Find the Force randomization for images section and select Off by default
• Reboot

It should be off by default, but i think Microsoft will switch that on by default in the future as more and more programs become compatible.

thankxx a ton