procps/testsuite/pwait.test/pwait.exp

49 lines
1.2 KiB
Plaintext
Raw Normal View History

#
# Dejagnu tests for pwait - part of procps
#
set mypid [pid]
set not_ppid [ expr { $mypid + 1 } ]
set pwait "${topdir}src/pwait"
set uid [ exec id -u ]
set not_uid [ expr { $uid + 1 } ]
set gid [ exec id -g ]
set not_gid [ expr { $gid + 1 } ]
if { ![ file exists $pwait ] } {
untested { skipping (not build)}
return
}
set test "pwait with no arguments"
spawn $pwait
expect_pass "$test" "^\(lt-\)\?pwait: no matching criteria specified\\s*"
make_testproc
pgrep: Support matching on the presence of a userspace signal handler In production we've had several incidents over the years where a process has a signal handler registered for SIGHUP or one of the SIGUSR signals which can be used to signal a request to reload configs, rotate log files, and the like. While this may seem harmless enough, what we've seen happen repeatedly is something like the following: 1. A process is using SIGHUP/SIGUSR[12] to request some application-handled state change -- reloading configs, rotating a log file, etc; 2. This kind of request is deprecated and removed, so the signal handler is removed. However, a site where the signal might be sent from is missed (often logrotate or a service manager); 3. Because the default disposition of these signals is terminal, sooner or later these applications are going to be sent SIGHUP or similar and end up unexpectedly killed. I know for a fact that we're not the only organisation experiencing this: in general, signal use is pretty tricky to reason about and safely remove because of the fairly aggressive SIG_DFL behaviour for some common signals, especially for SIGHUP which has a particularly ambiguous meaning. Especially in a large, highly interconnected codebase, reasoning about signal interactions between system configuration and applications can be highly complex, and it's inevitable that on occasion a callsite will be missed. In some cases the right call to avoid this will be to migrate services towards other forms of IPC for this purpose, but inevitably there will be some services which must continue using signals, so we need a safe way to support them. This patch adds support for the -H/--require-handler flag, which matches on processes with a userspace handler present for the signal being sent. With this flag we can enforce that all SIGHUP reload cases and SIGUSR equivalents use --require-handler. This effectively mitigates the case we've seen time and time again where SIGHUP is used to rotate log files or reload configs, but the sending site is mistakenly left present after the removal of signal handler, resulting in unintended termination of the process. Signed-off-by: Chris Down <chris@chrisdown.name>
2022-11-01 05:47:21 +05:30
set ps "${topdir}src/ps/pscommand"
set testproc1_sid [ string trim [ exec $ps --no-headers -o sid $testproc1_pid ] ]
set not_testproc1_sid [ expr { $testproc1_sid + 1 } ]
set test "pwait with not matching gid"
spawn $pwait -G $not_gid $testproc_comm
expect_blank $test
set test "pwait doesn't match with bogus parent pid"
spawn $pwait -P $not_ppid $testproc_comm
expect_blank "$test"
set test "pwait doesn't match with bogus sid"
pgrep: Support matching on the presence of a userspace signal handler In production we've had several incidents over the years where a process has a signal handler registered for SIGHUP or one of the SIGUSR signals which can be used to signal a request to reload configs, rotate log files, and the like. While this may seem harmless enough, what we've seen happen repeatedly is something like the following: 1. A process is using SIGHUP/SIGUSR[12] to request some application-handled state change -- reloading configs, rotating a log file, etc; 2. This kind of request is deprecated and removed, so the signal handler is removed. However, a site where the signal might be sent from is missed (often logrotate or a service manager); 3. Because the default disposition of these signals is terminal, sooner or later these applications are going to be sent SIGHUP or similar and end up unexpectedly killed. I know for a fact that we're not the only organisation experiencing this: in general, signal use is pretty tricky to reason about and safely remove because of the fairly aggressive SIG_DFL behaviour for some common signals, especially for SIGHUP which has a particularly ambiguous meaning. Especially in a large, highly interconnected codebase, reasoning about signal interactions between system configuration and applications can be highly complex, and it's inevitable that on occasion a callsite will be missed. In some cases the right call to avoid this will be to migrate services towards other forms of IPC for this purpose, but inevitably there will be some services which must continue using signals, so we need a safe way to support them. This patch adds support for the -H/--require-handler flag, which matches on processes with a userspace handler present for the signal being sent. With this flag we can enforce that all SIGHUP reload cases and SIGUSR equivalents use --require-handler. This effectively mitigates the case we've seen time and time again where SIGHUP is used to rotate log files or reload configs, but the sending site is mistakenly left present after the removal of signal handler, resulting in unintended termination of the process. Signed-off-by: Chris Down <chris@chrisdown.name>
2022-11-01 05:47:21 +05:30
spawn $pwait -s $not_testproc1_sid $testproc_comm
expect_blank "$test"
set test "pwait doesn't match with bogus tty"
spawn $pwait -t glass $testproc_comm
expect_blank "$test"
set test "pwait with not matching uid"
spawn $pwait -U $not_uid $testproc_comm
expect_blank $test
# Cleanup
kill_testproc