From nobody Wed Nov 27 13:04:09 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1550672754807893.7512466100825; Wed, 20 Feb 2019 06:25:54 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 113CEB2818; Wed, 20 Feb 2019 14:25:52 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C6EE161B95; Wed, 20 Feb 2019 14:25:51 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 7E2A03FB11; Wed, 20 Feb 2019 14:25:51 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x1KEPgK8017156 for ; Wed, 20 Feb 2019 09:25:42 -0500 Received: by smtp.corp.redhat.com (Postfix) id 217035D71A; Wed, 20 Feb 2019 14:25:42 +0000 (UTC) Received: from kinshicho.brq.redhat.com (unknown [10.43.2.212]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 971905D723 for ; Wed, 20 Feb 2019 14:25:41 +0000 (UTC) From: Andrea Bolognani To: libvir-list@redhat.com Date: Wed, 20 Feb 2019 15:25:00 +0100 Message-Id: <20190220142500.9810-5-abologna@redhat.com> In-Reply-To: <20190220142500.9810-1-abologna@redhat.com> References: <20190220142500.9810-1-abologna@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v4 4/4] util: Report error in virFileWrapperFdClose() X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 20 Feb 2019 14:25:53 +0000 (UTC) Content-Type: text/plain; charset="utf-8" libvirt_iohelper is used internally by the virFileWrapperFd APIs; more specifically, in the QEMU driver we have the doCoreDump() and qemuDomainSaveMemory() helper functions as users, and those in turn end up being called by the implementation of several driver APIs. By calling virReportError() if libvirt_iohelper has failed, we overwrite whatever generic error message QEMU might have raised with the more useful one generated by the helper program. After this commit, the user will be able to see the error directly instead of having to dig in the journal or libvirtd log. https://bugzilla.redhat.com/show_bug.cgi?id=3D1578741 Signed-off-by: Andrea Bolognani --- src/util/virfile.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/util/virfile.c b/src/util/virfile.c index d35206b0dd..31030c7b34 100644 --- a/src/util/virfile.c +++ b/src/util/virfile.c @@ -337,8 +337,14 @@ virFileWrapperFdClose(virFileWrapperFdPtr wfd) =20 ret =3D virCommandWait(wfd->cmd, NULL); =20 - if (wfd->err_msg && *wfd->err_msg) - VIR_WARN("iohelper reports: %s", wfd->err_msg); + /* If the command used to process I/O has failed and produced some + * messages on stderr, it's fair to assume those will be more + * relevant to the user than whatever eg. QEMU can figure out on its + * own having no knowledge of the fact a command is handling its I/O + * in the first place, so it's okay if we end up discarding an + * existing error here */ + if (ret < 0 && wfd->err_msg && *wfd->err_msg) + virReportError(VIR_ERR_OPERATION_FAILED, "%s", wfd->err_msg); =20 wfd->closed =3D true; =20 --=20 2.20.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list