From nobody Sun May 5 21:27:16 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1529501927022722.9117171520393; Wed, 20 Jun 2018 06:38:47 -0700 (PDT) Received: from localhost ([::1]:49745 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fVdJr-0006PY-3Z for importer@patchew.org; Wed, 20 Jun 2018 09:38:43 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56211) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fVd6W-00033F-26 for qemu-devel@nongnu.org; Wed, 20 Jun 2018 09:24:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fVd6S-0004Pn-3N for qemu-devel@nongnu.org; Wed, 20 Jun 2018 09:24:56 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:35516 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fVd6R-0004Pa-Up for qemu-devel@nongnu.org; Wed, 20 Jun 2018 09:24:52 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2B0EC738E6 for ; Wed, 20 Jun 2018 13:24:51 +0000 (UTC) Received: from dell-r430-03.lab.eng.brq.redhat.com (dell-r430-03.lab.eng.brq.redhat.com [10.37.153.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id C7EE57C24; Wed, 20 Jun 2018 13:24:49 +0000 (UTC) From: Igor Mammedov To: qemu-devel@nongnu.org Date: Wed, 20 Jun 2018 15:24:19 +0200 Message-Id: <1529501059-163139-1-git-send-email-imammedo@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 20 Jun 2018 13:24:51 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 20 Jun 2018 13:24:51 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'imammedo@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PATCH] vl.c: do not allow --daemonize in combination with --preconfig CLI option X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mprivozn@redhat.com, pkrempa@redhat.com, ehabkost@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" some users when using --daemonize expect that QEMU will parse CLI options, initialize VM and only then complete daemonzation by signalling lead process to exit and start listening on monitor socket. So users treat parent process exit as sync point to connect to QEMU's monitor. That however doesn't work when --preconfig options is used, since it provides monitor before completing daemonization and expects user to issue exit-preconfig command when additional configuration via monitor is finished. We also can't move completing daemonization before preconfig monitor becomes available, since that would imply: * partially loosing ability to configure QEMU instance in --preconfig mode since QEMU might drop privileges, chroot and do other things when daemonization is completed * lead to loss of error messages in case they would happen after daemonization Be proactive now and make options mutually exclusive, so users would get clear error message instead of waiting for lead process exit indefinitely before connecting to monitor. PS: In case someone would come up with usecase where both options should be enabled at the same time we could drop this restriction as far as daemonization point is left where it is now (os_setup_post). Signed-off-by: Igor Mammedov --- vl.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/vl.c b/vl.c index b3426e0..569bc7f 100644 --- a/vl.c +++ b/vl.c @@ -4134,6 +4134,12 @@ int main(int argc, char **argv, char **envp) } =20 if (is_daemonized()) { + if (!preconfig_exit_requested) { + error_report("'preconfig' and 'daemonize' options are " + "mutually exclusive"); + exit(EXIT_FAILURE); + } + /* According to documentation and historically, -nographic redirec= ts * serial port, parallel port and monitor to stdio, which does not= work * with -daemonize. We can redirect these to null instead, but si= nce --=20 2.7.4