From: Thomas Huth <thuth@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
Qemu-block <qemu-block@nongnu.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Coiby Xu" <coiby.xu@gmail.com>,
"Alexander Bulekov" <alxndr@bu.edu>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: [PATCH] tests/qtest/vhost-user-blk-test: Check whether qemu-storage-daemon is available
Date: Thu, 14 Oct 2021 08:45:42 +0200 [thread overview]
Message-ID: <e45f67c4-70c5-3891-4b8d-dfbff8dc6f3e@redhat.com> (raw)
In-Reply-To: <CAFEAcA_t48rMSX7SKnJNNMPXPmKpy12iXc2N41EywTBYfapKtg@mail.gmail.com>
On 11/08/2021 13.08, Peter Maydell wrote:
> On Wed, 11 Aug 2021 at 11:00, Thomas Huth <thuth@redhat.com> wrote:
>>
>> The vhost-user-blk-test currently hangs if QTEST_QEMU_STORAGE_DAEMON_BINARY
>> points to a non-existing binary. Let's improve this situation by checking
>> for the availability of the binary first, so we can fail gracefully if
>> it is not accessible.
>>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> ---
>> tests/qtest/vhost-user-blk-test.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/tests/qtest/vhost-user-blk-test.c b/tests/qtest/vhost-user-blk-test.c
>> index 8796c74ca4..6f108a1b62 100644
>> --- a/tests/qtest/vhost-user-blk-test.c
>> +++ b/tests/qtest/vhost-user-blk-test.c
>> @@ -789,6 +789,14 @@ static const char *qtest_qemu_storage_daemon_binary(void)
>> exit(0);
>> }
>>
>> + /* If we've got a path to the binary, check whether we can access it */
>> + if (strchr(qemu_storage_daemon_bin, '/') &&
>> + access(qemu_storage_daemon_bin, X_OK) != 0) {
>> + fprintf(stderr, "ERROR: '%s' is not accessible\n",
>> + qemu_storage_daemon_bin);
>> + exit(1);
>> + }
>
> It makes sense not to bother starting the test if the binary isn't
> even present, but why does the test hang? Shouldn't QEMU cleanly
> exit rather than hanging if it turns out that it can't contact
> the daemon ?
Sorry for the late reply: I think this happens due to the way we run that
qtest: The test program forks to run the storage daemon. If that daemon
binary is not available, or exits prematurely, the original program does not
notice and hangs. Maybe we should intercept the SIGCHLD signal for such cases?
Thomas
prev parent reply other threads:[~2021-10-14 6:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-11 9:59 [PATCH] tests/qtest/vhost-user-blk-test: Check whether qemu-storage-daemon is available Thomas Huth
2021-08-11 10:10 ` Alexander Bulekov
2021-08-11 11:08 ` Peter Maydell
2021-10-14 6:45 ` Thomas Huth [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e45f67c4-70c5-3891-4b8d-dfbff8dc6f3e@redhat.com \
--to=thuth@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=alxndr@bu.edu \
--cc=coiby.xu@gmail.com \
--cc=kwolf@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).