From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <t.lamprecht@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by lists.proxmox.com (Postfix) with ESMTPS id E84F58BE61
for <pve-devel@lists.proxmox.com>; Fri, 28 Oct 2022 09:40:03 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id C62237B0E
for <pve-devel@lists.proxmox.com>; Fri, 28 Oct 2022 09:40:03 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
[94.136.29.106])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by firstgate.proxmox.com (Proxmox) with ESMTPS
for <pve-devel@lists.proxmox.com>; Fri, 28 Oct 2022 09:40:02 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
by proxmox-new.maurer-it.com (Proxmox) with ESMTP id D6E9944C2F
for <pve-devel@lists.proxmox.com>; Fri, 28 Oct 2022 09:40:01 +0200 (CEST)
Message-ID: <aa6d47c2-26e2-d49c-3e89-f83ef5ee3996@proxmox.com>
Date: Fri, 28 Oct 2022 09:40:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:107.0) Gecko/20100101
Thunderbird/107.0
Content-Language: en-GB
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Fiona Ebner <f.ebner@proxmox.com>
References: <20221027081324.55998-1-f.ebner@proxmox.com>
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
In-Reply-To: <20221027081324.55998-1-f.ebner@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results: 0
AWL -0.034 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
NICE_REPLY_A -0.001 Looks like a legit reply (A)
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
Subject: Re: [pve-devel] [PATCH v2 qemu] init: daemonize: defuse PID file
resolve error to warning
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2022 07:40:04 -0000
On 27/10/2022 10:13, Fiona Ebner wrote:
> When proxmox-file-restore invokes QEMU, the PID file is a (temporary)
> file that's already unlinked, so resolving the absolute path here
> failed.
>
> It should not be a critical error when the PID file unlink handler
> can't be registered, because the path can't be resolved for whatever
> reason. Just turn it into a warning instead.
thx for the patch!
>
> Reported-by: Dominik Csapak <d.csapak@proxmox.com>
> Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
> ---
>
> Changes from v1:
> * Added R-b and S-b tags.
>
> softmmu/vl.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/softmmu/vl.c b/softmmu/vl.c
> index 0d233d55f3..1fa992ab09 100644
> --- a/softmmu/vl.c
> +++ b/softmmu/vl.c
> @@ -2445,10 +2445,9 @@ static void qemu_maybe_daemonize(const char *pid_file)
>
> pid_file_realpath = g_malloc0(PATH_MAX);
> if (!realpath(pid_file, pid_file_realpath)) {
> - error_report("cannot resolve PID file path: %s: %s",
> - pid_file, strerror(errno));
> - unlink(pid_file);
> - exit(1);
> + warn_report("not removing PID file on exit: cannot resolve path: "
> + "%s: %s", pid_file, strerror(errno));
As my reply to the upstream patch at Daniel's query w.r.t. to warn,
I'd also like to drop the warning here, at least for ENOENT, which
would cover our, and IMO most other, use cases.
> + return;
> }
>
> qemu_unlink_pidfile_notifier = (struct UnlinkPidfileNotifier) {