From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 44E891FF130 for ; Mon, 20 Jul 2026 17:41:36 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 78968214C3; Mon, 20 Jul 2026 17:41:35 +0200 (CEST) Message-ID: Date: Mon, 20 Jul 2026 17:41:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH manager] report: list recent reboot events and their kernel version To: Alexander Zeidler , Maximiliano Sandoval References: <20260720123649.226360-1-a.zeidler@proxmox.com> <55625334-51ae-45d8-b365-91d85d1cc541@proxmox.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1784562035671 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.216 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_LOW -0.7 Sender listed at https://www.dnswl.org/, low trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: FWQEXPI7NP7ONBVV46GCX643OJVUT6B5 X-Message-ID-Hash: FWQEXPI7NP7ONBVV46GCX643OJVUT6B5 X-MailFrom: t.lamprecht@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Am 20.07.26 um 16:58 schrieb Alexander Zeidler: > On Mon Jul 20, 2026 at 3:33 PM CEST, Maximiliano Sandoval wrote: >> Thomas Lamprecht writes: >>> For just the boots we could use "journalctl --list-boots -n 5 -r". >>> Depending on wtmpdb and writing yet another log file just for kernel version might >>> be a bit overkill, given that the info is there in the journal, albeit it *is* >>> annoying that we would have to manually parse them from the journal... >> >> For the purposes of support we are more interested about the kernel >> version used each boot. It would be interesting to have info about the >> BOOT IDs or having the timestamp of the last entry for a give boot >> though. >> >> Another consideration of journalctl is that the boots might be rotated >> away. > > While the mentioned `journalctl --list-boots -n 5 -r` does not include > the booted kernel versions, it lists at least a close timestamp of the > crash. > > I am not aware of a rotation issue, i.e., I think any rotation may apply > to the same extent to `wtmpdb` and `last`. Although a minor problem can > be when using e.g. the following command and there was no reboot since > then. But in such seldom cases we likely have to ask for more specific > journal information anyway. > > `journalctl --since "3 months ago" -g "Command line:|Journal stopped" -q | tail` > > The command is limited to 3 months, since the query can take several > seconds for journals that are flooded with entries. The advantage is, > that it also contains the kernel command lines used. A crash timestamp > is not available, but boot timestamps (usually shortly after finally > crashed) and whether a reboot/shutdown was performed gracefully. FWIW, we already got proxmox-mini-journalreader and it can already produce json that we could extend to produce the relevant info, i.e. iterating through boots (IIRC that is a indexed table) and parser first Line to extract the kernel. That could then be outputted as structured JSON there which can be parsed by the report here. In the midterm we could even think about integrating that as fully fledged API to our products API, if it can provide value as first class boot + kernel list there. For now just parsing the json in the report would be more than enough (or CLI only integration as middleground). You can try "poaching" one of our Devs that isn't to afraid from a bit of C to implement this, would be probably the safest course be here, especially as we maintain the journald handling already anyway.