Open marmarek opened 2 months ago
Since this test fails only sometimes, it's likely a race condition. My hypothesis is that qrexec-client
fails to send stdin data and exits with code 1, before handling exit code message received from the remote side. If I'm correct, this may also cause loosing some final messages from the service, if the client tried to send something at the same time. Again, if I'm correct, the solution is to handle remaining vchan messages even if sending failed already (but don't try to send any more data, and don't read from stdin anymore).
Observation
openQA test in scenario qubesos-4.3-pull-requests-x86_64-system_tests_usbproxy@64bit fails in TC_20_USBProxy_core3_whonix-gateway-17
Test suite description
Test removes
/etc/qubes-rpc/qubes.USBAttach
and then tries to execute it. It should fail with exit code 127, but as the above message says, it exited with code 1.Reproducible
Fails since (at least) Build 2024061215-4.3 (current job)
Expected result
Last good: 2024061115-4.3 (or more recent)
Further details
Always latest result in this scenario: latest