I updated the referred commit to fix a line ending issue. I will submit a pull request when I get an answer to how best to unit test this without hanging the unit tests

I'm currently running into the same issue. It was working fine until now. I'm not sure what change affected it.

I'm running on Java 1.8 and Jruby 1.7.9.

I am having what seems to be the same or similar problem too. It was fine until I upgraded from jruby 1.6.7 to 1.7.12.. Some percentage of the time when I run a command via system() it will get stuck and wait for me to press enter (the process that had been running is gone but jruby is still waiting)
I'm not sure if this is the exact same issue but I wrote this little script that will hang if you press enter... then it continues again if you press enter a second time.
The thing that is odd to me is that it is not consistent when I see it happen. I am executing cucumber from within another ruby script. When I changed jruby versions I went and replaced almost every single instance of system() to backticks because of this issue.

command = "ls /"
count = 0
while (count < 5000) do
puts count
puts system(command)
count += 1
end

I'd love to know how to avoid this. Backticks isn't a complete solution for me since the process that is running could take up to 2 or 3 hours to run and I need to be able to see the output from it while it is executing.
Earlier today I upgraded to 1.7.13 and the behavior is the same.

I am running my own compiled version of jruby with the fix I gave above. It is working great for me.

Here's a stack from a stuck process I just hit:
"main" prio=10 tid=0x00007f000c008000 nid=0x6941 in Object.wait() [0x00007f0010972000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1258)
- locked <0x00000000f6a9ebf8> (a org.jruby.util.ShellLauncher$StreamPumper)
at java.lang.Thread.join(Thread.java:1332)
at org.jruby.util.ShellLauncher.handleStreams(ShellLauncher.java:1522)
at org.jruby.util.ShellLauncher.runAndWaitPid(ShellLauncher.java:545)
at org.jruby.util.ShellLauncher.runAndWaitPid(ShellLauncher.java:400)
at org.jruby.RubyKernel.systemCommon(RubyKernel.java:1747)
at org.jruby.RubyKernel.system19(RubyKernel.java:1724)
at org.jruby.RubyKernel$INVOKER$s$0$0$system19.call(RubyKernel$INVOKER$s$0$0$system19.gen)
at org.jruby.internal.runtime.methods.JavaMethod$JavaMethodN.call(JavaMethod.java:665)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:206)
at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:168)
at org.jruby.ast.FCallOneArgNode.interpret(FCallOneArgNode.java:36)
at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:105)
at org.jruby.ast.BlockNode.interpret(BlockNode.java:71)
at org.jruby.ast.WhileNode.interpret(WhileNode.java:131)
at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:105)
at org.jruby.ast.BlockNode.interpret(BlockNode.java:71)
at org.jruby.evaluator.ASTInterpreter.INTERPRET_METHOD(ASTInterpreter.java:74)

works on Linux ... maybe this was a Windows specific issue on JRuby 1.7.x (EOL)
... someone should give JRuby 9K a spin and report back if its still relevant

Just checked, #system still blocks on 9.1.9.0 + Windows 7 (x64).

Hi, actually I'm working with JRuby 1.7.27 on Ubuntu 16.04 and it seems to have the same issue. In fact, the same thing happens with system, IO.popen, exec and net: ssh.

@Marcofeli I'm guessing you would not have this problem on JRuby 9.2.x, since in 9k we reimplemented process management (for POSIX systems) using true native process functions.

The rest of this issue is valid still, but duplicates many other issues that all have the same cause: we do not have native process management on JRuby yet. See also #4964 and others.