Errno::ESRCH when sending interrupt signal about parallel HOT 7 CLOSED

I'd rather find the cause then hide it :)

Seems to work fine on osx, can you e.g. put some puts into the code and see who kills the processes.
does it also happen with a smaller sleep ?

Maybe the processes get finished by the os because they are no longer connected via any pipes..

from parallel.

On the other hand if the process is really dead (no longer in the processlist) and the result is there, what do I care how it died :)

can you patch it, run it and see if there are any processes left over ?
ruby -e 'require "parallel"; Parallel.each([1,2,3]) {|n| sleep 60; puts n }; sleep 9999 + open another console and see if it shows up in the processlist

from parallel.

Sure, I've patched parallel with code similar to what I pasted above, and with debugging statements showing the process ID and child process ID's, and which are able to be killed, and which are not. I then increased the number of processes and items to 500. The 500 processes are created correctly, and ps shows 501 ruby processes (as expected). However, the break_on_ctrl_c method is only able to kill between 0 and 2 of these processes. When attempting to kill the others, they raise ESRCH. Adding an exception handler to the block being passed in, it appears that all 499 other child processes are receiving INT rather than KILL (they receive Ruby's Interrupt exception). After this occurs, none of the child processes are left (i.e. no zombies). I'm not sure how to tell who the sender of the signal is (or even if this is possible). In any case, from what I can tell, it looks like when the INT signal is sent to a process, it is automatically propagated to the child processes, but only by some operating systems (maybe to avoid zombies?). The kernel version for this machine is...

Linux sun006 3.2.0-29-generic-pae #46-Ubuntu SMP Fri Jul 27 17:25:43 UTC 2012 i686 i686 i386 GNU/Linux

Next I tried this on a Debian Stable (6.0.5) virtual machine with an older Linux kernel, and this error was also raised in that environment. From what I have seen so far, it looks like the behavior is basically dependent on which the child process gets first: INT or KILL. In most cases, the child gets INT rather than KILL. Kernel version for this Debian VM is...

Linux debian1 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686 GNU/Linux

Code for playing around with this included....

def self.kill_on_ctrl_c(pids)
  Signal.trap :SIGINT do
    $stderr.puts 'Parallel execution interrupted, exiting ...'

    $stderr.puts "#{Process.pid}: children are: #{pids}"
    pids.each do |pid|
      begin
        Process.kill(:KILL, pid)
        $stderr.puts "#{Process.pid}: YES, #{pid} is running"
      rescue Errno::ESRCH
        $stderr.puts "#{Process.pid}: NO, #{pid} is NOT running"
      end
    end

    $stderr.puts "#{Process.pid}: Going to bed for a long time!"
    sleep 9999
    exit 1 # Quit with 'failed' signal
  end
end

require "./parallel"
Parallel.each((1..500).collect.to_a, :in_processes=>500) do |p|
  begin
    sleep 9999
  rescue Exception => err
    $stderr.puts "#{Process.pid}: #{err.inspect}"
  end
end

Let me know if I can give any more information, or if there are any scenarios you would like to go over.

from parallel.

Perfect, just wanted to make sure were not leaving any children behind ;)
So I'll just add this to kill_on_ctrl_c ok ?

rescue Errno::ESRCH
   # Child PID already dead
end

from parallel.

Sure, that sounds good. Thank you. :-)

from parallel.

0.5.19 is all yours!

thanks for tracking this down, weird issue :)

from parallel.

Great, thank you for fixing this weird issue. I can confirm that on 0.5.19, Ctrl+C is now working perfectly.

from parallel.