SIGTERM signal is ignored by a process run using Ruby

[Luca Boero]

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

 

[ara.t.howard]

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

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/

 

[Arne Juul]

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:[email protected]: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:[email protected]: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.