From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8FEACECAAA1 for ; Fri, 28 Oct 2022 07:55:11 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ooKCW-0004de-Uc; Fri, 28 Oct 2022 03:54:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ooKCT-0004d5-VS for qemu-devel@nongnu.org; Fri, 28 Oct 2022 03:54:45 -0400 Received: from proxmox-new.maurer-it.com ([94.136.29.106]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ooKCE-0008TK-Hm for qemu-devel@nongnu.org; Fri, 28 Oct 2022 03:54:45 -0400 Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 65D1944C54; Fri, 28 Oct 2022 09:54:26 +0200 (CEST) Message-ID: Date: Fri, 28 Oct 2022 09:54:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [PATCH] vl: change PID file path resolve error to warning Content-Language: en-US To: Thomas Lamprecht , =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= Cc: qemu-devel@nongnu.org, pbonzini@redhat.com, hreitz@redhat.com, d.csapak@proxmox.com References: <20221027101443.118049-1-f.ebner@proxmox.com> <6fdd4b06-4c9b-5a7c-d16d-c3b362fecb81@proxmox.com> <7c7cfb50-fd32-f26e-7f82-5cedbe47c4bb@proxmox.com> From: Fiona Ebner In-Reply-To: <7c7cfb50-fd32-f26e-7f82-5cedbe47c4bb@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=94.136.29.106; envelope-from=f.ebner@proxmox.com; helo=proxmox-new.maurer-it.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Qemu-devel" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Am 28.10.22 um 09:26 schrieb Thomas Lamprecht: > On 28/10/2022 09:11, Fiona Ebner wrote: >> Am 27.10.22 um 14:17 schrieb Daniel P. Berrangé: >>> On Thu, Oct 27, 2022 at 12:14:43PM +0200, Fiona Ebner wrote: >>>> + warn_report("not removing PID file on exit: cannot resolve PID file" >>>> + " path: %s: %s", pid_file, strerror(errno)); >>>> + return; >>>> } >>> I don't think using warn_report is desirable here. >>> >>> If the behaviour of passing a pre-unlinked pidfile is considered >>> valid, then we should allow it without printing a warning every >>> time an application does this. >>> >>> warnings are to highlight non-fatal mistakes by applications, and >>> this is not a mistake, it is intentionally supported behaviour. >> >> But what if the path resolution fails in a scenario where the caller did >> not pre-unlik the PID file? Should the warning only be printed when the >> errno is not ENOENT? Might still not be accurate in all cases though. > > ENOENT would be IMO a good heuristic for silence, as I see no point in > warning that something won't be cleaned up if it's already gone from > POV of QEMU. > > Iff, I'd then personally only log at some level that shows up on > debug/high-verbosity settings, that should cover the a bit odd setups where, > e.g. the PID file is there but not visible to QEMU, e.g., because being > located in another mount namespace (in which case the management stack that > put it there probably wants to handle that more explicitly anyway). Or do > you meant something else with "not accurate in all cases"? > I did not have a concrete scenario in mind, just felt like there could be some edge case where we get ENOENT even though the file is not unlinked or maybe we get EACCES and can't tell if the file is already gone or not. Not sure what would happen in the scenario you described, but it might be one such edge case :) Best Regards, Fiona