Bug 2137935

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.

Fedora 40 

kernel 8.8.8-300.fc40.x86_64

libdnf-0.73.1-1.fc40.x86_64
python3-libdnf-0.73.1-1.fc40.x86_64
python3-dnf-4.19.2-1.fc40.noarch
dnf-4.19.2-1.fc40.noarch
dnfdaemon-selinux-0.3.22-1.fc40.noarch
dnfdaemon-0.3.22-1.fc40.noarch
python3-dnfdaemon-0.3.22-1.fc40.noarch
python3-dnf-plugins-core-4.6.0-1.fc40.noarch
dnf-plugins-core-4.6.0-1.fc40.noarch
dnfdragora-2.1.5-3.fc40.noarch
dnfdragora-updater-2.1.5-3.fc40.noarch



The following is still occurring after any update :-

# /usr/bin/dnf needs-restarting -r

Core libraries or services have been updated since boot-up:
  * dbus
  * dbus-broker
  * dbus-daemon
  * glibc
  * kernel
  * kernel-core
  * linux-firmware
  * microcode_ctl
  * systemd

Reboot is required to fully utilize these updates.
More information: https://access.redhat.com/solutions/27943