24

The basic problem is that sometimes when I do 

git pull upstream master

I get

remote: Counting objects: 172, done.
remote: Compressing objects: 100% (57/57), done.
remote: Total 119 (delta 45), reused 95 (delta 21)
      0 [main] git 8660 fork: child -1 - forked process 4520 died unexpectedly, retry 0, exit code -1073741515, errno 11
error: cannot fork() for index-pack: Resource temporarily unavailable
fatal: fetch-pack: unable to fork off index-pack

The exit code is the same every time, the number of objects varies as doe the process numbers of course. I am running with public key authentication against github via ssh on Windows 7. It happens with and without ssh-agent. I've been having this problem for several months now, and working around it by switching over to run Git Bash (MingW32), whenever it crops up, (which is almost every time with some repositories and occasionally or never with others). However I generally prefer the Cygwin environment and have most of my stuff setup there, so it's a drag when I'm forced to do that.

A while ago I saw this post http://cygwin.com/ml/cygwin/2012-03/msg00025.html and after reading it hoped that the next time I updated Cygwin that fix would fix my issue too. It didn't, but I wasn't sure if the fix was released, but I updated again today and it's happening.

I've noticed a plethora of emails about errors relating to fork() for Cygwin git on the web, though none for pull, and so my question is, has anyone seen this on pull before, what causes it? is there any way to keep it from happening (besides patching git or cygwin or using some other implementation course :) ).

Amusingly I've seen exactly none of the errors for which I can find relevant Cygwin/git mails on the web.

Gus
  • 6,719
  • 6
  • 37
  • 58
  • Same problem. I've also noticed that it seems to pop up whenever I do a git pull against a repository that has a large number of changes. ---Windows7+Cygwin+SSH against a private git repo – uhleeka Sep 12 '12 at 20:21
  • For what it's worth, I'm getting this with a Bash script which does fairly simple operations on text files and produces a CSV file. It doesn't make any external calls other than to `bc` (the bash calculator). I'm in Win7+Cygwin, running locally (no SSH) – HXCaine Dec 11 '12 at 23:58
  • This may also help some people (although I haven't tried it): http://superuser.com/questions/335907/cygwin-x-beginner-trouble – HXCaine Dec 12 '12 at 00:00

5 Answers5

35

This is addressed here: http://cygwin.wikia.com/wiki/Rebaseall

In short, close all windows and run this:

C:\cygwin\bin\dash.exe -c '/usr/bin/rebaseall -v'

This fixes all related issues with forking. I had issues with forking aspell from emacs as well as git.

Martin Thomson
  • 3,433
  • 2
  • 16
  • 13
  • 1
    Also, shutting down all Cygwin process can be a pain, but is necessary for this to work. Another helpful addendum is that it would not run from a command prompt window for me but from the actual "Run" command dialog it did work fine. – DrCord Sep 04 '14 at 15:52
  • Didn't work for me. I have `babun` (1.2.0) as my cygwin (1.7.35) installation. The fix with PATH manipulation worked fine – Denis Jun 27 '17 at 12:57
  • I had exactly the same issue and this answer resolved my issue! – chiefenne Sep 26 '18 at 12:56
26

OK, I guess I should share. I have the same problem, but I have a workaround. The problem seems to be the length of the PATH. If I do a git pull, I get the fork failure:

$ git pull*emphasized text*
      2 [main] git 7384 fork: child -1 - forked process 7420 died unexpectedly, retry 0, exit code -1073741515, errno 11
error: cannot fork() for rev-list: Resource temporarily unavailable
error: Could not run 'git rev-list'
remote: Counting objects: 728, done.
remote: Compressing objects: 100% (456/456), done.
 907550 [main] git 7384 fork: child -1 - forked process 7436 died unexpectedly, retry 0, exit code -1073741515, errno 11
error: cannot fork() for index-pack: Resource temporarily unavailable
fatal: fetch-pack: unable to fork off index-pack

However, if I set the PATH to something really small before running git, it works:

$ PATH=/usr/bin git pull
remote: Counting objects: 728, done.
remote: Compressing objects: 100% (456/456), done.
remote: Total 464 (delta 337), reused 9 (delta 6)
Receiving objects: 100% (464/464), 153.36 KiB, done.
Resolving deltas: 100% (337/337), completed with 107 local objects.
From git://cmake.org/cmake

I would be interested if it works for any of you?

Ярослав Рахматуллин
  • 7,599
  • 1
  • 41
  • 60
Bill Hoffman
  • 1,742
  • 11
  • 12
  • Unfortunately, I can no-longer test this, as I have moved on from the job where I was experiencing this problem. – Gus Nov 08 '12 at 01:00
  • thanks very much..I was struggling to make this work since last few days..tried with rebaseall also but your solution worked for me... – anand Nov 13 '12 at 03:34
  • Instead, of using the alias `git` just use the full path `/usr/bin/git`. – Rubens Mariuzzo Nov 15 '12 at 16:15
  • 1
    I tried to bring this up on the cygwin mailing list, but found no takers on helping so far. Glad to hear I am not alone with this issue... Rubens, for me if I use /usr/bin/git it still crashes. – Bill Hoffman Nov 19 '12 at 22:14
  • This fixed it! Thanks a lot for saving me a whole bunch of time. – Randomblue Jan 14 '13 at 15:31
  • 1
    Ok based on the fact that several people say this has worked for them, I'm going to award this a checkmark. – Gus Jan 14 '13 at 18:42
  • Dude, I've been beating my head against the wall with this for a year at least, this is the first thing I've read that actually helps. I can't thank you enough. Put a Paypal button up there :) – smendola Apr 08 '13 at 20:24
  • I finally saw this solution in action. One of my clients had the problem and I gave him the solution :) – Gus Jun 27 '13 at 22:39
  • 2
    The below answer to rebaseall is a MUCH better answer, and fully explains the problem (including why this hack solves the immediate problem). – Bryan Sep 04 '13 at 06:52
  • Actually the problems it is NOT the length of the path itself, but rather the position of gits entry in that path. Having a very long path works fine, when you make sure that your git entry in the path variable is within the first 2048 characters of the path after all shortcuts in the path got fully expanded. It worked for me without shortening my path after moving git more into the front of the path. Still upvoting. I would never had thought that PATH could be the issue without this answer. – Kaiserludi Apr 19 '17 at 13:15
4

I also faced same problem and restart of the system resolved it.

RootCode
  • 569
  • 7
  • 12
2

I get that some time has passed, but I found this searching for my own very similar issue, using the cygwin platform built into the MobaXterm app. Was pulling my nonexistent hair out trying to figure it out, in the end it was fixed by a simple restart.

I double verified that this worked with a second Windows 10 machine, a new installation of MobaXterm + git apps, and an attempt to pull from a github repo. Same error: "error: cannot fork() for index-pack: Resource temporarily unavailable" was achieved, and a simple computer reboot fixed it.

N Phillip Cole NPC
  • 21
  • 1
  • I had to reinstall MobaXterm, then reinstall. The reboot was not enough on its own, the reinstall was not enough on its own. But with their powers combined! Thank you NPC! – Curtis Boyden Apr 03 '18 at 17:26
-3

Instead of setting the PATH variable or using git's full path (once), this should work as well:

git=`which git`
git pull

This will assign git to it's full path for consecutive calls. Now, if git is used in another program(like make), it will be able to.

codesnip3r
  • 140
  • 1
  • 3
  • What you've written won't do much of anything, you're not using the variable you set. And it's a bit pointless anyway given you have to specify the path at least once, or have it in PATH to begin with. – Mat Aug 28 '13 at 05:57
  • The variable is being used...not sure what you're talking about. After setting it, echo $git confirms this. Anyway, it solved the issue for me so...guess I'm the only one. – codesnip3r Aug 28 '13 at 07:58
  • Nevermind, I see what you're saying. It does solve the problem for me though...not sure why, but it does. – codesnip3r Aug 28 '13 at 08:06
  • Look at the code you posted closely. `git pull` and `$git pull` are two completely different statements (potentially). – Mat Aug 28 '13 at 08:16
  • Yes, I see that now (it is late). But like I said, it works...hell maybe setting ANY variable does the trick?? I'll give it a try and report back next time it happens to me. – codesnip3r Aug 28 '13 at 08:25
  • Ok, I just disproved that my answer actually DOES NOT work...forget I even mentioned it :( Thanks for opening my eyes Mat – codesnip3r Aug 28 '13 at 08:34