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

JRuby automatically reaps child pids #2684

Closed
dotboris opened this Issue Mar 11, 2015 · 2 comments

Comments

Projects
None yet
3 participants
@dotboris

dotboris commented Mar 11, 2015

it seems like jruby automatically reaps child pids. This is different from MRI.

The following script demonstrates this.

pid = Process.spawn 'cat' # waits forever
Process.kill 15, pid
Process.wait pid

puts 'all is good'

When run with MRI I get:

$ ruby test.rb
all is good

When I run it with jruby I get:

$ jruby test.rb
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
Errno::ECHILD: No child processes - No child processes
  waitpid at org/jruby/RubyProcess.java:536
     wait at org/jruby/RubyProcess.java:563
     wait at org/jruby/RubyProcess.java:558
   (root) at test.rb:3

This is not always the case, sometimes I get:

$ jruby test.rb
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
all is good

I am running the following versions:

$ ruby --version
ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]
$ jruby --version
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd
jruby 1.7.18 (1.9.3p551) 2014-12-22 625381c on Java HotSpot(TM) 64-Bit Server VM 1.8.0_31-b13 +jit [linux-amd64]

I am guessing that either jruby or the jvm automatically reaps it's children. When I get the error, it's when the child was reaped before I could call Process#kill. When I don't get the error, it's because I managed to call Process#wait before the child process was automatically reaped.

@monkstone

This comment has been minimized.

Show comment
Hide comment
@monkstone

monkstone Mar 12, 2015

Contributor

The good news it is your test passes with latest jruby 9.0.0.0-SNAPSHOT (2.2.1) 2015-03-12 06be1c0 OpenJDK 64-Bit Server VM 25.31-b07 on 1.8.0_31-b13 +jit [linux-amd64] and I get same failure as you with jruby-1.7.18

Contributor

monkstone commented Mar 12, 2015

The good news it is your test passes with latest jruby 9.0.0.0-SNAPSHOT (2.2.1) 2015-03-12 06be1c0 OpenJDK 64-Bit Server VM 25.31-b07 on 1.8.0_31-b13 +jit [linux-amd64] and I get same failure as you with jruby-1.7.18

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Mar 12, 2015

Member

Yeah, on 9k this should act like MRI because we're using real native process logic which will require you to waitpid on your own. In JRuby 1.7, however, we're using the JDK's process logic, and that logic does indeed immediately do its own waitpid on the child, so it can provide a thread that blocks until the child has completed (similar to MRI's Process.detach but ALL THE TIME).

There won't be an easy way to fix this in 1.7 due to the JDK, but we can mark this fixed in 9k.

Member

headius commented Mar 12, 2015

Yeah, on 9k this should act like MRI because we're using real native process logic which will require you to waitpid on your own. In JRuby 1.7, however, we're using the JDK's process logic, and that logic does indeed immediately do its own waitpid on the child, so it can provide a thread that blocks until the child has completed (similar to MRI's Process.detach but ALL THE TIME).

There won't be an easy way to fix this in 1.7 due to the JDK, but we can mark this fixed in 9k.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment