From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 831741FF0B3 for ; Wed, 14 Oct 2026 11:52:23 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 0F4FE2147C; Wed, 14 Oct 2026 11:52:21 +0200 (CEST) Message-ID: <8c5bb528-88f0-49fd-86e9-d3e4d16d16e9@proxmox.com> Date: Wed, 14 Oct 2026 11:52:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH kernel-helper] kernel hooks: flag pending reboot after installing a new kernel To: Jonas Theisen , pve-devel@lists.proxmox.com References: <20261013114721.198258-1-j.theisen@proxmox.com> <90364d0b-95b7-4aaf-bb43-ff10dad3eb7e@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: 1791971534314 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.555 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_MED -2.3 Sender listed at https://www.dnswl.org/, medium 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: 2ZBT36JURYLQTJDLSSSQ7DUOF7JMFQND X-Message-ID-Hash: 2ZBT36JURYLQTJDLSSSQ7DUOF7JMFQND 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 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 14.10.26 um 11:37 schrieb Jonas Theisen: > On 10/14/26 10:35, Thomas Lamprecht wrote: >> Am 13.10.26 um 13:47 schrieb Jonas Theisen: >>> Ship a postinst.d hook that writes /run/reboot-required and records >>> the kernel package in /run/reboot-required.pkgs, similar to >>> the hooks shipped by unattended-upgrades on Debian and >>> update-notifier on Ubuntu. Tools like needrestart or monitoring checks >>> can then notice that the newly installed kernel is not running yet, >>> without requiring one of those packages to be installed. >> Any reference to those docs/code/... that describe these file (paths) >> would be appreciated here. > > From https://github.com/mvo5/unattended-upgrades > > unattended-upgrade: > > 105 REBOOT_REQUIRED_FILE = "/var/run/reboot-required" > [...] > 867 def reboot_required(): > 868 # type: () -> bool > 869 return os.path.isfile(REBOOT_REQUIRED_FILE) > > kernel/postinst.d/unattended-upgrades: > > 8 if [ -d /var/run ]; then > 9 touch /var/run/reboot-required > 10 if ! grep -q "^$DPKG_MAINTSCRIPT_PACKAGE$" /var/run/reboot-required.pkgs 2> /dev/null ; then > 11 echo "$DPKG_MAINTSCRIPT_PACKAGE" >> /var/run/reboot-required.pkgs > 12 fi > 13 fi > > From https://github.com/liske/needrestart > > data/update-motd-reboot-required > > 5 if [ -f /var/run/reboot-required ]; then > 6 cat /var/run/reboot-required > 7 fi > > Since `/var/run` is just a symlink to `/run` i figured we should use > the current specification. > > Should i also include these refs in the commit message? Yes, please, at least in some basic prose form describing how this is checked/used with [X] reference to the repo/file/docs/... >>> +echo "*** System restart required ***" > /run/reboot-required >> >> That's always truncating any existing reboot-required file though? >> Or doesn't that matter because it will be either not there or contain >> exactly this string? In any case, needs either fixing or mentioning >> that its fine in the commit message and maybe even a short > > According to my understanding of this files usage it is just checked > for existence and printed in the motd. The content seems to be irrelevant. Ack, then it's at least not that problematic, but potentially still not nice to blindly override it? Did you check how others - e.g. debian or ubuntu handles this for kernel updates? As just adding a lot of complexity with not much gain is not really worth it either, but maybe others came up with a sensible solution here already.