Bug 2137935
Summary: | dnf needs-restarting always true | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | todd_lewis |
Component: | dnf-plugins-core | Assignee: | Jan Kolarik <jkolarik> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | 37 | CC: | amatej, awilliam, bdm, bfinger, bradley.g.smith, daniel.mach, jkolarik, jmracek, jrohel, mblaha, mhatina, packaging-team-maint, pkratoch, praiskup, robatino, rpm-software-management, vmukhame |
Target Milestone: | --- | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | aarch64 | ||
OS: | Linux | ||
Whiteboard: | RejectedBlocker | ||
Fixed In Version: | dnf-plugins-core-4.4.0-1.fc37 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2023-04-08 02:36:25 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
todd_lewis
2022-10-26 15:57:56 UTC
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? 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. |