From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pve-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
by lore.proxmox.com (Postfix) with ESMTPS id 8D94D1FF37F
for <inbox@lore.proxmox.com>; 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 <a.zeidler@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
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 <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>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: pve-devel-bounces@lists.proxmox.com
Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com>
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 <a.zeidler@proxmox.com>
> > ---
> > 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