backend: exit non-zero when a job process is killed by a signal - #2129
Open
Vladyyy wants to merge 1 commit into
Open
backend: exit non-zero when a job process is killed by a signal#2129Vladyyy wants to merge 1 commit into
Vladyyy wants to merge 1 commit into
Conversation
When a forked job process dies from a fatal signal (SIGABRT from a failed assert(), SIGSEGV, OOM kill), reap_threads() logs "fio: pid=..., got signal=..." and records td->sig, but never sets td->error. The reaped: label only counts td->error into exit_value, so the main fio process exits 0 and the job summary prints err= 0 for the crashed job. The WIFEXITED branch right below does propagate a non-zero exit status, so a worker that exits(1) fails the run while a worker that crashes reports success, defeating any automation that checks fio's exit code. Mark an unexpectedly signaled worker as failed by setting td->error (EINTR) next to the existing log_err. SIGTERM and SIGUSR2 stay excluded, matching the log message: fio uses them for orderly termination. Setting td->error rather than bumping exit_value directly keeps the accounting in one place and makes the job summary show a non-zero err for the crashed job. Tested by sending SIGABRT to one worker of a two-job process-based run: the crashed job now reports err= 4 and fio exits 1 (both were 0 before); a crash-free run still reports err= 0 for all jobs and exits 0. Fixes: axboe#2127 Signed-off-by: Vlad Tudose <tudosevt@amazon.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a forked job process dies from a fatal signal (SIGABRT from a
failed assert(), SIGSEGV, OOM kill), reap_threads() logs
"fio: pid=..., got signal=..." and records td->sig, but never sets
td->error. The reaped: label only counts td->error into exit_value, so
the main fio process exits 0 and the job summary prints err= 0 for the
crashed job. The WIFEXITED branch right below does propagate a
non-zero exit status, so a worker that exits(1) fails the run while a
worker that crashes reports success, defeating any automation that
checks fio's exit code.
Mark an unexpectedly signaled worker as failed by setting td->error
(EINTR) next to the existing log_err. SIGTERM and SIGUSR2 stay
excluded, matching the log message: fio uses them for orderly
termination. Setting td->error rather than bumping exit_value directly
keeps the accounting in one place and makes the job summary show a
non-zero err for the crashed job.
Tested by sending SIGABRT to one worker of a two-job process-based
run: the crashed job now reports err= 4 and fio exits 1 (both were 0
before); a crash-free run still reports err= 0 for all jobs and
exits 0.
Fixes: #2127
Signed-off-by: Vlad Tudose tudosevt@amazon.com