Description of problem: `dnf needs-restarting -r` always claims dbus, dbus-broker, dbus-daemon, glibc, kernel, linux-firmware, and systemd have been updated since boot-up, even immediately after boot-up. Version-Release number of selected component (if applicable): dnf-4.14.0-1.fc37.noarch How reproducible: always Steps to Reproduce: 1. reboot 2. run `dnf needs-restarting -r` 3. Actual results: # dnf needs-restarting -r Core libraries or services have been updated since boot-up: * dbus * dbus-broker * dbus-daemon * glibc * kernel * linux-firmware * systemd Reboot is required to fully utilize these updates. More information: https://access.redhat.com/solutions/27943 Expected results: # dnf needs-restarting -r No core libraries or services have been updated since boot-up. Reboot should not be necessary. Additional info: Because this host is a "Raspberry Pi 3 Model B+" which has no real time clock, the initial clock value on boot apparently is being set by the compile time of some component. Pure speculation, but could dnf be grabbing the timestamp on the first record of the equivalent of `journalctl -b` -- which is demonstrably wrong b/c the clock was wrong -- instead of the first date-time shown for `journalctl --list-boots | tail -n 1` -- which is correct?
Proposed as a Blocker for 37-final by Fedora user coremodule using the blocker tracking app because: Proposing as a potential F37 as a possible violation of the "Installing, removing and updating software" criterion. [0] [0] https://fedoraproject.org/wiki/Fedora_37_Final_Release_Criteria#Installing,_removing_and_updating_software
Just tried this with the same dnf version. [bdm@deangelis ~]$ dnf needs-restarting -r No core libraries or services have been updated since boot-up. Reboot should not be necessary. Works for me.
/usr/lib/python3.11/site-packages/dnf-plugins/needs_restarting.py determines boot time by checking st_mtime of /proc/1 @staticmethod def get_boot_time(): return int(os.stat('/proc/1').st_mtime) which is 0 on my current system # ls -ld /proc/1 dr-xr-xr-x. 9 root root 0 Dec 31 1969 /proc/1
BTW: `uptime` shows the correct values on the same system where /proc/1 st_mtime is 0. `strace uptime` shows that "uptime" reads "/proc/uptime". This is kernel-5.19.16-301.fc37.aarch64 on a "Raspberry Pi 3 Model B+".
The only reliable method of determining boot time I've found on this system is to subtract /proc/uptime's seconds from the current time. The following diff seems to do the Right Thing: --- /usr/lib/python3.11/site-packages/dnf-plugins/needs_restarting.py-1666868784 2022-09-23 02:50:37.000000000 -0400 +++ /usr/lib/python3.11/site-packages/dnf-plugins/needs_restarting.py 2022-10-27 07:45:10.683280191 -0400 @@ -34,6 +34,7 @@ import os import re import stat +import time # For which package updates we should recommend a reboot @@ -199,7 +200,9 @@ @staticmethod def get_boot_time(): - return int(os.stat('/proc/1').st_mtime) + with open('/proc/uptime') as uptime: + uptimes = uptime.read().strip().split() + return time.time() - int(uptimes[0].split('.')[0]) @staticmethod def get_sc_clk_tck():
Paying more attention to types, that should return an int: return int(time.time() - float(uptimes[0]))
-8 in https://pagure.io/fedora-qa/blocker-review/issue/988 , marking rejected.
(In reply to Brian Morrison from comment #2) > Just tried this with the same dnf version. > > [bdm@deangelis ~]$ dnf needs-restarting -r > No core libraries or services have been updated since boot-up. > Reboot should not be necessary. > > Works for me. Does that system have an Real Time Clock?
Related PR: https://github.com/rpm-software-management/dnf-plugins-core/pull/466
Yes, it's running on an Asus H370Mplus motherboard, fairly standard PC.
As @amatej mentioned in the previous comment (https://bugzilla.redhat.com/show_bug.cgi?id=2137935#c9), this solution is already being discussed in the https://github.com/rpm-software-management/dnf-plugins-core/pull/466 PR, more comments are there. But as for now, this change seems to break the existing functionality for the systemd-nspawn containers. I've also added a linked bugzilla here: https://bugzilla.redhat.com/show_bug.cgi?id=1913962.
For machines which have no real time clock, such as Raspberry Pi 3 Model B+, the system boots at the beginning of the epoch: > # stat -c %y /proc/1 > 1969-12-31 19:00:04.539999998 -0500 thus `needs-restarting` is always true. Perhaps the better solution is to take the greater of the two values: - int(os.stat('/proc/1').st_mtime) - current time minus /proc/uptime's seconds (as per this patch). That should continue to work reliably on bare metal (even after hibernation), virtual machines, podman containers, and systemd-nspawn containers, _AND_ will also start to work on machines which boot with clocks set hopelessly far into the past -- assuming of course that the current time is reasonably correct.
There's a PR implementing the suggestion in comment #12 https://github.com/rpm-software-management/dnf-plugins-core/pull/468
Fixed by the PR mentioned in comment 13. Thanks Todd!
Glad to see the PR in comment #13. This "problem" has been vexing me on the 4 Pis I run in a home lab.
FEDORA-2023-1b65a60b93 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-1b65a60b93
FEDORA-2023-1b65a60b93 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-1b65a60b93` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-1b65a60b93 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-1b65a60b93 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.