Try to retrieve exit code of a failed service call #183
Conversation
This file contains 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
When service call fails, the remote (service) side sends EOF + exit code and closes the vchan immediately. If the client side tries to send something, it will fail and exit immediately (with code 1). But reading data that was queued in the vchan before its closing is still possible. So, on send error check if there is anything interesting to receive (especially exit code, but potentially also some service output) and, if yes, don't exit immediately. Since the service exit code is sent last (after all stdout/stderr data and their EOF), it's okay to check just for remote_status. This is relevant only to the service client side, as exit status of the service-handling process is not relevant. Fixes QubesOS/qubes-issues#9618
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #183 +/- ##
==========================================
+ Coverage 79.05% 79.11% +0.05%
==========================================
Files 54 54
Lines 9916 9953 +37
==========================================
+ Hits 7839 7874 +35
- Misses 2077 2079 +2 ☔ View full report in Codecov by Sentry. |
This was referenced Dec 3, 2024
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2024121004-4.3&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2024111705-4.3&flavor=update
Failed tests4 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/119126#dependencies 2 fixed
Unstable tests
|
This was referenced Dec 3, 2024
Merged
Check if the service exit code is correctly retrieved even if the the service terminates at the exact moment the qrexec-client tries to send some data. Try to win the race by initially sending SIGSTOP to the qrexec-client process, and sending SIGCONT only after preparing both local and remote data streams. qrexec-client will handle local data stream first, at which point remote socket is already closed. Similar issue applies to qrexec-client-vm, but since the implementation is shared, one test is enough. QubesOS/qubes-issues#9618
marmarek
force-pushed
the
exec-fail-code
branch
from
55fa313 to
df25090
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 service call fails, the remote (service) side sends EOF + exit code
and closes the vchan immediately. If the client side tries to send
something, it will fail and exit immediately (with code 1). But reading
data that was queued in the vchan before its closing is still possible.
So, on send error check if there is anything interesting to receive
(especially exit code, but potentially also some service output) and, if
yes, don't exit immediately. Since the service exit code is sent last
(after all stdout/stderr data and their EOF), it's okay to check just
for remote_status.
This is relevant only to the service client side, as exit status of the
service-handling process is not relevant.
Fixes QubesOS/qubes-issues#9618