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>
This avoids situations where longer regex which matches short-named proc
is used. Test for pgrep updated.
This is the newlib update of 5d12be1b7e8cc690a4d8778754aae5db4c07db2b
Signed-off-by: Craig Small <csmall@enc.com.au>
Add a warning if you specify a command over 15 characters and don't
use the -f command.
This is a pick of two patches from master:
24fd260 pgrep: Fix off by one error in line check
4a7f9fc pgrep - adds warning that pattern exceeds 15 chars without
References:
!25
For the test suite, procps used to use sleep which would just
create a process or two to test the tools against. Some setups
coreutils creates all programs including sleep into one blob which
means a lot of the tests fail, see issue #2
procps has its own sleep program now.
On most systems the only process with a SID=1 is init
and certainly not a test sleep. On docker systems this
test program IS on SID=1 and so our "impossible SID" becomes
possible.
The ps sched test has been disabled. There are too many
odd build farms this fails in strange ways.
Other odd build farms have no tty and so some tests check
for no tty and skip if not found.
It seems command -v also includes built-ins so checking for kill
is useless because it finds the built-in and those machines or
environments that have no /bin/kill fail at the check stage.
Oh and then TCL exec doesn't spawn a shell.
After reading way too many TCL websites, I believe this should
fix the problem. TCL quoting is... different to say the least but
it works reliably here. The script now even picked up a typo elsewhere
which was nice.
This change should stop the intermittent FTBFS bugs from the Debian
pbuilders, I hope! You'd think kill $var wouldn't be this difficult.
Some Debian pbuilders error out on some of the tests because
they cannot find kill to kill the test processes. Now if we
cannot find kill we skip those lot of tests.
Still need to work out why the S390 doesn't like test_sched
References: http://bugs.debian.org/725743
When ps is not available (like it may happen in a chroot), pgrep.exp and pkill.exp tests fail.
Use just build ps instead.
Signed-off-by: Gilles Espinasse <g.esp@free.fr>
