From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 8D94D1FF37F for ; Thu, 18 Apr 2024 17:46:24 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 40CFB306CE; Thu, 18 Apr 2024 17:46:24 +0200 (CEST) Message-ID: <891f5346072232e5b4a9b1dabdfc54eea3b74170.camel@proxmox.com> From: Alexander Zeidler To: Proxmox VE development discussion Date: Thu, 18 Apr 2024 17:45:49 +0200 In-Reply-To: <5b8d83bb-70de-46dc-bbd5-7cd71d4d1ee0@proxmox.com> References: <20240418091650.51366-1-a.zeidler@proxmox.com> <20240418091650.51366-7-a.zeidler@proxmox.com> <5b8d83bb-70de-46dc-bbd5-7cd71d4d1ee0@proxmox.com> User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.062 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 POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [report.pm, proxmox.com] Subject: Re: [pve-devel] [PATCH manager 7/7] report: add recent boot timestamps which may show fencing/crash events X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On Thu, 2024-04-18 at 12:43 +0200, Mira Limbeck wrote: > On 4/18/24 11:16, Alexander Zeidler wrote: > > Successful boots which crashed somehow and sometime afterwards, will > > show the same "until" value ("still running" or timestamp) as the next > > following boot(s). The most recent boot from such a sequence of > > duplicated "until" lines, has not been crashed or not yet. > > > > Example output where only the boot from 16:25:41 crashed: > > reboot system boot 6.5.11-7-pve Thu Apr 11 16:31:24 2024 still running > > reboot system boot 6.5.11-7-pve Thu Apr 11 16:29:17 2024 - Thu Apr 11 16:31:12 2024 (00:01) > > reboot system boot 6.5.11-7-pve Thu Apr 11 16:25:41 2024 - Thu Apr 11 16:31:12 2024 (00:05) > > ... > > > > Furthermore, it shows the booted/crashed/problematic kernel version. > > > > `last` is also used since currently `journalctl --list-boots` can take > > 10 seconds or even longer on some systems, with no option to limit the > > amount of reported boot lines. > > > > Signed-off-by: Alexander Zeidler > > --- > > v2: > > * move away from dmesg base > > * list also recent (5) boot timestamps with additional information > > > > v1: https://lists.proxmox.com/pipermail/pve-devel/2024-March/062342.html > > > > > > PVE/Report.pm | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/PVE/Report.pm b/PVE/Report.pm > > index d9f81a0f..c3abb776 100644 > > --- a/PVE/Report.pm > > +++ b/PVE/Report.pm > > @@ -32,6 +32,7 @@ my $init_report_cmds = sub { > > 'hostname', > > 'date -R', > > 'cat /proc/cmdline', > > + 'last reboot -F -n5', > > 'pveversion --verbose', > > 'cat /etc/hosts', > > 'pvesubscription get', > > Do we want the reboot info that far up, even above the version output? > I'd say it's less interesting most of the time than the `pveversion` output. I'm not sure if it really fits better with your suggestion. Because, while the pveversion output can be considered as often more relevant, I have placed it as it is because it fits well with the surrounding information: * You can see/compare the booted kernel versions to the kernel command line and pveversion output. * For the kernel command line it makes rather sense to have it at the beginning of the report. * Also it may be interesting how frequent the host is rebooted (e.g. after kernel updates) Btw. the "wtmp begins ..." output does not have to be the installation date. In case we do not store this information somewhere, currently something like stat / | grep Birth could be used if needed. > > And for uptime, we do have /cluster/resources and `top` which both show it. > Maybe it could be moved a bit further down? After /cluster/resources > could perhaps be a nice spot since it is (currently) followed by `top`? _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel