JRuby automatically reaps child pids

[dotboris]

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]

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]

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.