Add signal selection when stopping the process

[pevtsoff]

Hi Erik,

If this is possible, would you please add a feature to be able to state a signaly type sent when stopping the process. like this
1.Default stop would still go without parameters and would behave as it does now, which is very good rally
Process(stop)
2.But in case you want to send some particular signal from this ruby list (Signal.list in IRB)
{"EXIT"=>0, "INT"=>2, "ILL"=>4, "ABRT"=>22, "FPE"=>8, "KILL"=>9, "SEGV"=>11, "TERM"=>15}
It would be possible to call stop with parameter like
@process.stop(:sig_int) or
@process.stop(Signal.list['EXIT']) whichever is more appropriat`e for Ruby conventions

This would really help to use this package for automated application testing, as we would need to test like a case that the process finishes gracefully when CTRL+C (INT signal) is received by the process. And I think it would add more flexibility for testing purpose anyway

Thanks a lot
Ivan

[pevtsoff]

In particular, I'm interested in INT and may be TERM signal, so that I can test if it's correctly handled by our apps in auto test framework

[enkessler]

@pevtsoff , I'm not sure that this can be done. Signal.list does not seem to limit its signals based on what the operating system will accept. Process#kill seems to only accept KILL as a valid signal for Windows and after digging around in the project history, the only supported Windows signals seem to be INT, BREAK, and KILL since the project first started. Looking around online, it seems that Windows does not support signals in the same way that Unix-like systems do. Interrupting and breaking may be as graceful as one can get with Windows.

Have you actually successfully sent a TERM signal to a Windows process?

[pevtsoff]

Hi Eric Sorry for the long time response - I was very busy on the project. I think you are right - it's not that easy for Ruby on WIndows, but I have tried the following: 1.Running Process.kill for other outer windows processes with TERM, KILL and INT works only for KILL signal irb(main):009:0> Process.kill('INT',33152) Errno::EINVAL: Invalid argument from (irb):9:in `kill' from (irb):9 from C:/Ruby/Ruby23-x64/bin/irb.cmd:19:in `<main>' irb(main):010:0> Process.kill('TERM',33152) Errno::EINVAL: Invalid argument from (irb):10:in `kill' from (irb):10 from C:/Ruby/Ruby23-x64/bin/irb.cmd:19:in `<main>' irb(main):011:0> Process.kill('KILL',33152) => 1 2.Running Process.kill for some processes that were launched under ruby, say with ChildProcess gem can handle KILL and INT. The KILL signal processed properly, killing the application. The TERM signal is ignored, and the "INT" signal is handled some strange way. When Called it from within Cucumber - it seems it got caught by the whole current process group where the Cucumber is, and thus Cucumber caught it first and asked if I want to shutdown: THis is a pry line from within Cucumber test launch. [6] pry(#<EiraSystem::Rmshub>)> Process.kill('INT',3584) ^CTerminate batch job (Y/N)? And finally it shuts down everything ) So, looks like Ruby can handle the INT signal, but some strange way. Please see yourself if you can handle the INT signal gracefully on windows, and whether it's worth to start development. I didn't know it would cause some troubles for Ruby. Node.js can handle it quite well though.. Regards, Ivan

…

On 4 April 2017 at 02:06, Eric Kessler ***@***.***> wrote: @pevtsoff <https://github.com/pevtsoff> , I'm not sure that this can be done. Signal.list does not seem to limit its signals based on what the operating system will accept. Process#kill seems to only accept KILL as a valid signal for Windows and after digging around in the project history, the only supported Windows signals seem to be INT, BREAK, and KILL since the project first started. Looking around online, it seems that Windows does not support signals in the same way that Unix-like systems do. Interrupting and breaking may be as graceful as one can get with Windows. Have you actually successfully sent a TERM signal to a Windows process? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#114 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZjRRNgsKtjsssQ_OuaJnO8h8sAEP0eyks5rsZepgaJpZM4MwiHw> .

[enkessler]

@pevtsoff I haven't made any progress on this and I don't have any more time to dedicate to investigating it, unfortunately. You can keep poking at it if you want to and if you come up with something then I'm happy to look at a PR. For the moment, however, I'm closing the issue because all signs point to arbitrary signals not being possible on Windows.