Feature #18513
closed
Print "exited from signal XY" for exit codes >128
Description
When a program exits from a signal, crunch-run prints this:
Container exited with code: 139
Instead, this should say something like "Exited with signal 11 (SIGSEGV)" because most people don't actually know that exit codes over 128 mean exiting due to an unhandled signal, and nobody likes doing math.
Updated by Peter Amstutz about 3 years ago
- Status changed from New to In Progress
Updated by Peter Amstutz about 3 years ago
- Status changed from In Progress to New
- Description updated (diff)
Updated by Peter Amstutz almost 3 years ago
- Target version set to 2022-01-19 sprint
- Assigned To set to Tom Clegg
Updated by Tom Clegg almost 3 years ago
- Status changed from New to In Progress
- Container exited with status code 100
- Container exited with status code 228 (signal 100)
- Container exited with status code 137 (signal 9, SIGKILL)
While I was in the vicinity I figured we could test that the container executors actually return exit codes and signal numbers this way (as opposed to the "wait status" format where the exit code is in higher bits). This worked except that I couldn't get any variation of "docker run busybox sh -c 'kill -9 $$'" to work. Perhaps injecting a Go program that divides by zero would work? For now, this test just skips the docker case. For now I guess we've seen enough "exited 137" to know it works that way.
18513-log-signal-exit @ 3b9c4641a985a53347696b7a77bcde28a92d6e79 -- developer-run-tests: #2878
Updated by Lucas Di Pentima almost 3 years ago
This LGTM and I think will be super helpful for debugging. Thanks!
Updated by Tom Clegg almost 3 years ago
- Status changed from In Progress to Resolved
Applied in changeset arvados-private:commit:arvados|dd056538060528e6f7b7b48183dfcaeac7882638.
Updated by Peter Amstutz over 2 years ago
- Related to Feature #17301: Special case report exit_code 137 as likely out of memory error added