SIGTERM signal is ignored by a process run using Ruby

ruby-talk
1

Hello Everybody,
I am using Ruby 1.8.5 in a Rails 1.2.5 environment.
My code starts a dhcp-3.1.0 service taken from
http://www.isc.org/products/DHCP
Once started the dhcpd process cannot be stopped using the normal
"/etc/init.d/dhcp stop"
as it seems not to catch SIGTERM (signal 15) used within the service
script.
Can anyone help me, as it is 2 days I am unusefully fighting ?
Thank you in advance,
Luca

···

--
Posted via http://www.ruby-forum.com/.

2

no offense - but this doesn't have anything to do with ruby does it? the dhcp script is normally a /bin/sh script and i assume yours it too?

if not, and it's ruby - modify the call the 'trap' so SIGTERM is not caught.

if it is /bin/sh, and SIGTERM is trapped, you will have to figure out which signal to send. Process.kill(-9, pid) will work, but i'd strive to understand *why* dhcp prefers to trap SIGTERM and determine how it is supposed to be shut down. if there is no correct way file a bug with the maintainers of that code.

regards.

a @ http://codeforpeople.com/

···

On Nov 29, 2007, at 9:17 AM, Luca Boero wrote:

Hello Everybody,
I am using Ruby 1.8.5 in a Rails 1.2.5 environment.
My code starts a dhcp-3.1.0 service taken from
http://www.isc.org/products/DHCP
Once started the dhcpd process cannot be stopped using the normal
"/etc/init.d/dhcp stop"
as it seems not to catch SIGTERM (signal 15) used within the service
script.
Can anyone help me, as it is 2 days I am unusefully fighting ?
Thank you in advance,
Luca
-- Posted via http://www.ruby-forum.com/\.

--
it is not enough to be compassionate. you must act.
h.h. the 14th dalai lama

3

Luca Boero wrote:

I am using Ruby 1.8.5 in a Rails 1.2.5 environment.
My code starts a dhcp-3.1.0 service taken from
http://www.isc.org/products/DHCP
Once started the dhcpd process cannot be stopped using the normal
"/etc/init.d/dhcp stop"
as it seems not to catch SIGTERM (signal 15) used within the service
script.

here's a late confirmation: this is definitely a bug in ruby 1.8.5,
which looks like it's fixed in 1.8.6.

here's a small test program to verify if you have the bug:

previous_handler = trap('TERM') { raise RuntimeError, "signal" }
puts "prev handler:"
puts previous_handler
myhandler = trap('TERM', previous_handler)
puts "temp handler:"
puts myhandler
nhandler = trap('TERM', previous_handler)
puts "handler after restore:"
puts nhandler

puts `echo test self-kill; kill $$; echo should not get here, that is a
bug`

trap('TERM', "DEFAULT")
defhandler = trap('TERM', "DEFAULT")
puts "handler should be default, is:"
puts defhandler

correct output would look like this:

prev handler:
DEFAULT
temp handler:
#<Proc:0xbb8245a4@ttrap.rb:2>
handler after restore:
DEFAULT
test self-kill
handler should be default, is:
DEFAULT

but when I test it on 1.8.5 I get this instead:

prev handler:
nil
temp handler:
#<Proc:0x0000002a955a5bd0@ttrap.rb:2>
handler after restore:
IGNORE
test self-kill
should not get here, that is a bug
handler should be default, is:
nil

  - Arne H. J.

···

--
Posted via http://www.ruby-forum.com/\.