| commit | 731e87e9620c629d7506396f89726bb61825fc95 | [log] [tgz] |
|---|---|---|
| author | jacobsa <jacobsa@google.com> | Wed Sep 23 02:19:27 2020 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Wed Sep 23 02:20:25 2020 -0700 |
| tree | ab2e29dbdfd2d5f10e654b5da00f425df70f6e29 | |
| parent | 40746c9c5f6cfec69f81d50064dda2208a6444ed [diff] |
linux-sandbox: make delayed kill send SIGKILL instead of SIGALRM. Before this change, the kill delay feature caused SIGALRM, which can be caught. The intent appears to be to use SIGLARM to decide when to upgrade a SIGTERM to something that can't be caught, but of course SIGALRM _can_ be caught. This is a problem because linux-sandbox-pid1.cc does catch SIGALRM (and does the wrong thing with it in certain conditions: http://b/168848201). The only reason test_child_ignores_sigterm passes is because SIGALRM's default action is also to terminate the process, and the bash script used here as the grandchild process didn't trap that signal. Because we muck around with the exit status of the child (https://bit.ly/2Hc7IX1) and therefore grandchild (https://bit.ly/2FS8EQ1), the test saw an exit status for SIGTERM as it expected. In this change I've changed the test to also trap SIGLARM, and indeed without the changes to the code under test it now no longer passes, instead just getting stuck forever. The fix is to actually raise SIGKILL, as expected. To make the code involved less baffling I've gone from a "enumerate every signal" approach to "mention only those signals we have a reason to mention". I will do the same for linux-sandbox-pid1.cc in a future change. Behavior change: a kill delay of zero seconds is no longer a special case: instead of waiting forever for the child to deal with SIGTERM we now just SIGKILL it immediately, as the name implies. Behavior change: we no longer attempt to massage the exit status of the child process (which is what hid this bug from the test). Instead we return it directly. In particular this means that we may return zero even after a timeout (see test_signal_catcher), but this seems fine: this program is supposed to be a pass-through, and if the application says it was successful then who are we to disagree? PiperOrigin-RevId: 333251901
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
See CONTRIBUTING.md
