1

A couple of cloud servers we recently provisioned seem to ignore signals by default. I can figure out what has been configured to cause this behaviour and it is affecting both ctrl+c and bash scripts that rely on trapping signals.

This can be demonstrated using the sleep command, contrasting a server in this environment that works (set up several years ago) vs one of the affected ones.

me@working.server ~ $ sleep 300 &
[1] 9554
me@working.server ~ $ cat /proc/9554/status
Name:   sleep
Umask:  0002
State:  S (sleeping)
Tgid:   9554
<snip /> ...
SigQ:   0/63430
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000000000000
<snip /> ...
me@working.server ~ $ kill -s SIGINT 9554
me@working.server ~ $
me@working.server ~ $
[1]+  Interrupt               sleep 300
me@working.server ~ $ ps aux | grep [s]leep

The same commands run on one of our cloud VMs produces:

me@broken.server ~ $ sleep 300 &
[1] 2199
me@broken.server ~ $ cat /proc/2199/status
Name:   sleep
Umask:  0002
State:  S (sleeping)
Tgid:   2199
Ngid:   0
Pid:    2199
<snip /> ...
SigQ:   0/482668
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000006   <-- note the Signal Ignore flag are set
SigCgt: 0000000000000000
<snip /> ...
me@broken.server ~ $ kill -s SIGINT 2199
me@broken.server ~ $ ps aux | grep [s]leep
me        2199  0.0  0.0 107952   360 pts/1    S    16:35   0:00 sleep 300
me@broken.server ~ $ sudo kill -s SIGINT 2199
me@broken.server ~ $ ps aux | grep [s]leep
me        2199  0.0  0.0 107952   360 pts/1    S    16:35   0:00 sleep 300
me@broken.server ~ $ sudo kill -s SIGKILL 2199
[1]+  Killed                  sleep 300

At first I thought that this was some SSH issue affecting my pty, however this doesn't seem to be the case, and having come across this U&L question I found to look in the status of the running processes and found that this server seems to start any and all processes running with a base set of signals ignored.

I can't find anywhere that details how you'd set up those signals being blocked for any process that you start. Has anyone every come across something like this before?

Dan
  • 121
  • 1
    Notice that if you ignore a signal in a process, that disposition will be inherited by its children. Also look at the programs / scripts / processes (if still running) that had started those scripts. The way to ignore a signal in a shell script is with trap '' SIG or trap "" SIG; grep for it. –  Mar 25 '19 at 17:05

1 Answers1

1

For anyone who comes across a similar issue, in this particular case the problem was being caused by a bug in Ruby's Virtual Machine v1.27.4 that was installed on these cloud servers as part of the image.

The RVM bug was the scripts that override normal functions (like cd) where trapping SIGINT but not releasing it on clean up. More details can be found here Ruby RVM bug

The fix in this case was to update RVM to the latest stable (in this case 1.29.7).

curl -sSL https://get.rvm.io | bash -s stable --ruby

Thanks to mosvy for the pointer.

Dan
  • 121