Bug #14196
closedSignal.trap overrides pre-existing "SIG_IGN" handler on a process
Description
Came across while debugging an issue with bundler https://github.com/bundler/bundler/issues/6150
The issue is, if a process already has a SIG_IGN
/ IGNORE
present on it, then doing a Signal.trap
overrides the handler on the same process. I believe, if a process already has a SIG_IGN
then the same should be respected/restore.
This is how I am able to replicate the issue (from a linux machine where /proc
is mounted).
Sample ruby file for testing (test.rb)
p Signal.trap("SIGHUP", "IGNORE")
p Signal.trap("SIGHUP", "SYSTEM_DEFAULT") # This returns the correct string, `IGNORE`, but does not update the signal handler.
sleep 100
Here we are replicating a scenario where a process first gets a trap from SIG_IGN
and then a SYSTEM_DEFAULT
/ DEFAULT
. Next, run it
ruby test.rb 2>&2 &
[1] 23156
Now, lets see what signals are reserved on this status:
cat /proc/23156/status
Name: ruby
Umask: 0022
State: S (sleeping)
Tgid: 23156
Ngid: 0
Pid: 23156
PPid: 52
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 256
Groups:
NStgid: 23156
NSpid: 23156
NSpgid: 23156
NSsid: 52
VmPeak: 40508 kB
VmSize: 40508 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 8036 kB
VmRSS: 8036 kB
RssAnon: 3596 kB
RssFile: 4440 kB
RssShmem: 0 kB
VmData: 5192 kB
VmStk: 8188 kB
VmExe: 4 kB
VmLib: 6624 kB
VmPTE: 88 kB
VmPMD: 12 kB
VmSwap: 0 kB
HugetlbPages: 0 kB
Threads: 2
SigQ: 0/7753
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 00000001c2007e4e
CapInh: 00000000a80425fb
CapPrm: 00000000a80425fb
CapEff: 00000000a80425fb
CapBnd: 00000000a80425fb
CapAmb: 0000000000000000
Seccomp: 2
Cpus_allowed: f
Cpus_allowed_list: 0-3
Mems_allowed: 1
Mems_allowed_list: 0
voluntary_ctxt_switches: 1
nonvoluntary_ctxt_switches: 8
You'll notice that SigIgn
is 0000000000000000
which a bitmask and is indicating no IGNORE handlers on the process is reserved.
I have a fix/patch with specs, which I will share soon on Github for further insight. I would love to learn thoughts on this :).