zombie processes

[zimbatm]

Just found that issue, I don't have the time to investigate yet:

(master)⚡ % irb
ruby-1.8.7-p334 :001 > require 'open4'
 => true 
ruby-1.8.7-p334 :002 > Open4.spawn 'fsdsdsdfdf' rescue $!
 => #<Errno::ENOENT: No such file or directory - fsdsdsdfdf> 
ruby-1.8.7-p334 :003 > Process.waitall
 => [[46141, #<Process::Status: pid=46141,exited(1)>]] 
ruby-1.8.7-p334 :004 > 

If you don't wait for the pid, a zombie process is going to hang around

[noahgibbs]

Is this different from how things work in other libraries? I'm used to this problem with all similar Unix-based facilities...

[zimbatm]

Yes, people often get bitten by this posix particularity. In that case, it's Open4's responsibility to not leave zombies alive when the process dies.

[noahgibbs]

openface: shouldn't you be doing a detach or wait or something to harvest the child process?

[zimbatm]

Yes I could wait on the pid but I don't have access to it. It's not returned by the API and $? is empty because of Open4's double-fork.

[robertgrimm]

I've noticed this as well and agree with zimbatm's comments. It looks like the popen4 method should call 'Process.waitpid2(cid)' if the exec call raises an exception. It appears that a zombie process could also be left hanging around if the block, if used in block form, raises an exception. Perhaps move the existing Process.waitpid2 call to the ensure block?

Shouldn't it also ensure that all pipe endpoints are closed in this path? It looks like pw.last, pr.first and pe.first won't get closed in the original post's example.