Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kernel.system hangs if sub process spawns child #838

Closed
halfnelson opened this issue Jul 1, 2013 · 9 comments
Closed

Kernel.system hangs if sub process spawns child #838

halfnelson opened this issue Jul 1, 2013 · 9 comments

Comments

@halfnelson
Copy link

Calling kernel.system with a command that spawns any other process causes the system call to not return until that spawned process is ended. Same as bug http://jira.codehaus.org/browse/JRUBY-4470.

File: testsystem.rb

system('start notepad')
puts "done"

MRI

> ruby testsystem.rb
done

>

JRuby

> ruby testsystem.rb
[HANG]

I tracked the problem down to an assumption in ShellLauncher that when a process is closed all handles to stdin/out will be closed, but in this case the sub process inherits handles (on windows anyway) and even though the process is complete (process.waitFor does not block) the runPidAndWait will sit waiting for the stream pumps to rejoin the main thread.

I have patched the function to make it work properly here halfnelson@33114bc

I still need to forcibly stop the input thread. That is another bug. I will file separately.

How do I go about writing a unit test for this, since the failure case means the code never returns? Spawn the request in another thread and add a timeout? Downside of that is it makes unit tests slower.

@halfnelson
Copy link
Author

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

@bijanx
Copy link

bijanx commented Jun 11, 2014

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.

@cozmogeek
Copy link

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.

@halfnelson
Copy link
Author

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

@cozmogeek
Copy link

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)

@kares
Copy link
Member

kares commented May 22, 2017

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

@kares kares closed this as completed May 22, 2017
@kares kares added this to the Won't Fix milestone May 22, 2017
@MSNexploder
Copy link
Contributor

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

@kares kares reopened this May 22, 2017
@kares kares removed this from the Won't Fix milestone May 22, 2017
@kares kares added the windows label May 22, 2017
@Marcofeli
Copy link

Marcofeli commented Nov 7, 2018

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.

@headius
Copy link
Member

headius commented Sep 19, 2019

@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.

@headius headius closed this as completed Sep 19, 2019
@headius headius added this to the Invalid or Duplicate milestone Sep 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants