Nothing seems to work. "fork: retry: no child processes"
Closed this issue · 18 comments
After using the rubygems release for a while, I just installed this from the latest release linked on github
I tried both 1.0.0 and 0.10.0, both with the same result:
this crashes my system for a while (it seems no new processes can be spawn at this time. things like opening a chrome tab or trying to take a screenshot just hang). After a while, or if I pkill -f staging quickly enough, the system recovers.
Hi, can you provide some further information about your OS version and the line that sets your stag alias?
@geoffharcourt sorry, totally forgot about that
stag is a simple alias stag=staging
my machine is running Arch Linux:
$ uname -a
Linux naps62subvisual 4.7.6-1-ARCH #1 SMP PREEMPT Fri Sep 30 19:28:42 CEST 2016 x86_64 GNU/Linux
The releases I tried were: parity-1.0.0-linux-x86_64.tar.gz and parity-0.10.0-linux-x86_64.tar.gz
I later tried to install the older 0.10.0 via rubygems, and that one seems to run fine.
PS: linuxbrew doesn't seem to be an option for me. I had never used it, and when I tried it earlier it ended up trying to compile a lot of base dependencies such as perl and other basic things
@naps62 one more question, can you paste the output of ulimit -a here? I'm trying to see if you're bumping up against a process limit.
@geoffharcourt here you go. I also tested it just now to make sure these current limits also don't work (I was having other issues with ulimit a few days ago, so had to double check that). Once again, it yielded the same errors
± ulimit -a
-t: cpu time (seconds) unlimited
-f: file size (blocks) unlimited
-d: data seg size (kbytes) unlimited
-s: stack size (kbytes) 8192
-c: core file size (blocks) unlimited
-m: resident set size (kbytes) unlimited
-u: processes 63926
-n: file descriptors 10000
-l: locked-in-memory size (kbytes) 64
-v: address space (kbytes) unlimited
-x: file locks unlimited
-i: pending signals 63926
-q: bytes in POSIX msg queues 819200
-e: max nice 0
-r: max rt priority 0
-N 15: unlimitedDoes just staging on its own work?
And just to make sure, what does this produce: cat $(which staging)
@mike-burns tested once again to answer your question. I explicitly ran the binary from the downloads directory. Screenshot below.
This time I noticed the following new info:
- This also happens even if the repository doesn't have parity set up (no staging/production remotes). This app isn't even hosted on heroku
- It also happens if I just run the staging command outside of a git repository altogether
- It took 3 attempts to take this screenshot. Because the command just hangs for a few seconds, and when the fork error shows up it's usually too late, and the whole system crashes (no new processes can be started)
PS: all this was also tested with the current one I have from rubygems, and no problems showed up with that one
OK, if it's hanging when you've passed no arguments, that's suspicious. Did you also get the fork errors then, too?
I suspect line 1: #!/usr/bin/env ruby. Can you do some debugging around that for us: run /usr/bin/env ruby and confirm that works; show type -a ruby and let us know if that's the right one?
@mike-burns oh yeah, I didn't even notice this was an older screenshot, and didn't have the error. Then the last one probably failed as well
It's like I said above. Once the error shows up, no new processes can start (so I can't take a screenshot)
But yes, the same error does show up. It usually takes about 5 to 10 seconds
I'd be quite happy to have text pasted at me instead of a screenshot. Some debugging questions:
type -a ruby- looks reasonable?/usr/bin/env rubyshould run the Ruby interpreter; kill it with^c. But does that have trouble forking?
@mike-burns was so focused trying to get the screenshot on time, I didn't even remember that copy&paste existed 😛
not sure if this is what you meant, but all seems to be good here:
(I pressed ^d to end the ruby input, not ^c)
I also noticed just now that your tar.gz release includes a binary for ruby 2.2.2p95, while I'm running ruby 2.3.1. Could this be related?
I'm now trying to install ruby 2.2.2 to test that out, but it seems even that is not working (might be some rvm issue)
OK, you got me to download it and try it myself. You're right, it doesn't work on Linux (Linux autumn 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux).
well, that's a shame 😞
if you have any guesses as to why that might happen, I have some investment tomorrow where I could try to track this down.
It's actually interesting to me that a supposedly harmless binary is able to mess up with my system on this level
If you check ps ax | grep bash after running it, you'll see why. (pkill /bin/bash after that.)
I think the next step is to remove Traveling Ruby.
This has been on my wishlist for a while, now we have a reason. For now I'd fall back to the pre-1.x Ruby gem, and we'll cut a new version with executables if removing Traveling Ruby takes too long.
The actual non-Traveling Ruby code works, so if you can install parity-1.0.0-linux-x86_64/lib/app/bin/staging as the staging command, you'll be good. This won't be trivial to install -- it expects files in a specific path -- but pretty straightforward with some Ruby knowledge.
I'm making progress on removing Traveling Ruby and relying on the user's installed system Ruby, will update as that becomes ready for testing.
@NaPs I've added back installation of the executables via Rubygems as of version 2.0.0. I'm going to tackle a more ambitious effort for Linux packaging soon, but for now the best way to get the parity excutables would be to install version 2.0.0 or later from Rubygems. Thanks for your patience, and apologies for the inconvenience.
👍 thanks for fixing in the gem distribution and documenting here.