On Tue, Jun 25, 2019 at 05:32:15PM -0400, Theodore Ts'o wrote:
> <...>
>
> (In particular it might be worth checking Linux ports of Oracle and
> DB2.)
A couple of weeks of asking around got me to have a look at a DB2 9.7
instance.
sn1:~ # uname -a
Linux sn1 2.6.16.60-0.54.5-ppc64 #1 SMP Fri Sep 4 01:28:03 UTC 2009 ppc64 ppc64 ppc64 GNU/Linux
That particular deployment used the following set of processes:
sn1:~ # ps -eo user,ppid,pid,pgid,sid,tty,state,cmd | grep db2 | grep -v java
bgpsysdb 8505 672 8504 7146 ? S db2fmp ( ,0,0,0,0,0,0,0,1,0,8a6678,14,1e014,2,0,1,171fc0,0x110000000,0x110000000,1600000,18002,2,384f00b7
bgpsysdb 8505 687 8504 7146 ? S db2fmp ( ,0,0,0,0,0,0,0,1,0,8a6678,14,1e014,2,0,1,191fc0,0x110000000,0x110000000,1600000,18002,2,384f80b9
bgpsysdb 8505 4309 8504 7146 ? S db2fmp ( ,0,0,0,0,0,0,0,1,0,8a6678,14,1e014,2,0,1,151fc0,0x110000000,0x110000000,1600000,18002,2,6f5080c5
root 1 8505 8504 7146 ? S db2wdog 0
bgpsysdb 8505 8511 8511 7146 ? S db2sysc 0
root 8511 8512 8511 7146 ? S db2ckpwd 0
root 8511 8513 8511 7146 ? S db2ckpwd 0
root 8511 8514 8511 7146 ? S db2ckpwd 0
bgpsysdb 8505 8630 8504 7146 ? S db2acd 0 ,0,0,0,1,0,0,0,1,0,8a6678,14,1e014,2,0,1,11fc0,0x110000000,0x110000000,1600000,18002,2,398072
bgpsysdb 8505 15280 8504 7146 ? S db2fmp ( ,1,0,0,0,0,0,0,1,0,8a6678,14,1e014,2,0,1,31fc0,0x110000000,0x110000000,1600000,18002,2,bd80bb
bgpsysdb 8505 16032 8504 7146 ? S db2fmp ( ,0,0,0,0,0,0,0,1,0,8a6678,14,1e014,2,0,1,b1fc0,0x110000000,0x110000000,1600000,18002,2,81980ba
bgpsysdb 8505 16073 8504 7146 ? S db2fmp ( ,0,0,0,0,0,0,0,1,0,8a6678,14,1e014,2,0,1,91fc0,0x110000000,0x110000000,1600000,18002,2,12300c0
bgpsysdb 8505 17683 8504 7146 ? S db2fmp ( ,0,0,0,0,0,0,0,1,0,8a6678,14,1e014,2,0,1,131fc0,0x110000000,0x110000000,1600000,18002,2,248600db
bgpsysdb 8505 30731 8504 7146 ? S db2fmp ( ,0,0,0,0,0,0,0,1,0,8a6678,14,1e014,2,0,1,f1fc0,0x110000000,0x110000000,1600000,18002,2,370080d1
None of them has a controlling tty, so ^T pressed at any tty won't send
them a signal.
To get an idea on how do they handle signals, we can look at
/proc/*/status:
sn1:~ # cat /proc/{8512,8505,687,8511}/status | egrep '^(Pid|Sig|Shd)'
Pid: 687
SigQ: 0/128000
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: fffffffe2bbaf007
SigCgt: 00000001c44004f8
Pid: 8505
SigQ: 0/128000
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: fffffffe7ffbfeff
SigIgn: fffffffe2fbaf007
SigCgt: 00000001c0410ef8
Pid: 8511
SigQ: 0/128000
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: fffffffe7ffbfeff
SigIgn: fffffffe23b3c005
SigCgt: 00000001dc483efa
Pid: 8512
SigQ: 0/128000
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: fffffffe2fbbf007
SigCgt: 00000001c0400ef8
It can be seen from the above that SIGPWR in particular is always
ignored and sometimes blocked, which means its default disposition has
no effect.
This leads me to think that DB2 in particular would be unaffected by the
patch set.
p.s.: I do not have shell access to the machine, and never did; the commands
cited in this email were executed by a person who does, and the output
was handed back to me.
Attachment:
signature.asc
Description: PGP signature
