From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <f.ebner@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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 470D892145 for <pve-devel@lists.proxmox.com>; Thu, 1 Feb 2024 10:31:24 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 26806C70A for <pve-devel@lists.proxmox.com>; Thu, 1 Feb 2024 10:30:54 +0100 (CET) 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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pve-devel@lists.proxmox.com>; Thu, 1 Feb 2024 10:30:49 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id C434D41E15 for <pve-devel@lists.proxmox.com>; Thu, 1 Feb 2024 10:30:49 +0100 (CET) Message-ID: <85ffd3b2-ecb0-4354-a391-ff31134c7dc3@proxmox.com> Date: Thu, 1 Feb 2024 10:30:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US From: Fiona Ebner <f.ebner@proxmox.com> To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>, Friedrich Weber <f.weber@proxmox.com> Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20240118111147.131727-1-f.weber@proxmox.com> <ac021341-a61c-4491-b198-77901ec7be01@proxmox.com> <ac28c299-3079-4030-b45c-014beceeb7d9@proxmox.com> <4f959cf9-5068-4c14-aaf6-885f9cbf982a@proxmox.com> <74530bb6-6ccc-4b6e-ae3e-c1411fd7f4d7@proxmox.com> <9dc55104-f106-4602-9100-7eeac227caa7@proxmox.com> In-Reply-To: <9dc55104-f106-4602-9100-7eeac227caa7@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.073 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH v2 storage] lvm: improve warning in case vgs output contains unexpected lines 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: Thu, 01 Feb 2024 09:31:24 -0000 Am 01.02.24 um 10:20 schrieb Fiona Ebner: > Am 31.01.24 um 12:55 schrieb Friedrich Weber: >> >> After changing `warn` to `log_warn` I noticed that pvestatd does not >> write the warning to the syslog every 10s anymore. Turns out `warn` >> triggers a custom __WARN__ handler we install for our daemons which also >> writes to syslog (e.g. pvestatd [1]). But `log_warn` only writes to >> stderr [2], thus the `log_warn` warning is not written to the syslog. >> >> Briefly discussed with Fiona off-list, she suggested to try replacing >> `print` in `log_warn` with `warn` [2]. But with this, all `log_warn` >> warnings also appear in the syslog (e.g. the "no efidisk configured" >> warning [3]), which I think would be too spammy. >> > > But that is the original intention behind the __WARN__ handler. I'd > argue that replacing a warn with a log_warn() shouldn't change these > semantics. The intention of log_warn() was to make warnings more visible > in task logs. Making them less visible outside of tasks was not intended! > > The issue that task warnings also appear in syslog for pvedaemon and > others is a bit orthogonal and can be fixed too. > > My proposed solutions: > > 1) Switch to using "warn" instead of "print STDERR" in log_warn() and > either: > 1A) Clear the inherited __WARN__ handler in fork_worker(). > 1B) Have the __WARN__ handler check if it's in a worker and only log to > syslog if it's not. > The above would also address instances of "warn" (and not just log_warn()) that currently end up in syslog even though they happen in a task worker. OTOH, one could argue such warnings are not visible enough if not also logged to syslog, because there is no task warning count and it's not obvious you should read the task log. > 2. Keep using "print STDERR" in log_warn() and do print to syslog there > if not in a worker. We'd also need to check that it's not an interactive invocation, because for those it should also not log to syslog.