Bug 1754609
| Summary: | Modify default dnf-automatic unit timers | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Marion Levine <malevine> |
| Component: | dnf | Assignee: | Lukáš Hrázký <lhrazky> |
| Status: | CLOSED ERRATA | QA Contact: | Luca Berton <lberton> |
| Severity: | medium | Docs Contact: | Katerina Nemcova <knemcova> |
| Priority: | medium | ||
| Version: | 8.0 | CC: | amatej, carl, james.antill, knemcova, lberton, lhrazky, malevine, tony.garcia, troy.engel |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | 8.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | dnf-4.2.17-1.el8 | Doc Type: | Enhancement |
| Doc Text: |
.All `dnf-automatic.timer` timer units now use the real-time clock by default
Previously, the `dnf-automatic.timer` timer units used the monotonic clock, which resulted in unpredictable activation time after the system boot. With this update, the timer units run between 6 a.m. and 7 a.m. If the system is off during that time, the timer units are activated within one hour after the system boot.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-04-28 16:48:13 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
Marion Levine
2019-09-23 17:21:56 UTC
FTR I'll say that any single timer configuration is unlikely to suit everyone and a customer can configure the timers to fit their needs. That said, having deterministic timing is certainly better than nondeterministic. With regards to the time to use as the default, I don't have a better guidance than what was posted in the description and as that is used in Debian/Ubuntu as well, I've used the exact same configuration: [Timer] OnCalendar=*-*-* 6:00 RandomizedDelaySec=60m Persistent=true PR: https://github.com/rpm-software-management/dnf/pull/1521 Eva, I see no reason to have different timing on the various timers we provide. The timers differ in what operation they perform, providing the user with a choice of the operation they want to perform on the timed event. Regardless of whether the user wants to notify only, download or install, the timing should be consistent between the timers, IMO. As I've stated, it is well possible the change will be disruptive to someone. Our approach should be to provide the best default and let users change it in case they really need to. I've evaluated the requested change to be better enough than what we had before to change the default, but this is obviously subjective... :) FWIW there's also this bug against monotonic timers: https://bugzilla.redhat.com/show_bug.cgi?id=1648785 I think realtime timers are better in general. Katerina, I'd just mention the time is _random_ between 6 and 7 am, just to be more explicit about it. If you think it's redundant it's fine by me. Otherwise it's good. This has been resolved in CentOS 8 Stream. https://lists.centos.org/pipermail/centos-devel/2020-January/036500.html Please test this and provide feedback if you're able. @Carl I'm unable to do a full, proper test right now (nothing handy is running Stream yet to get all the other dnf upgrades required) but I manually pulled down the RPM, expanded it and at least confirm the timer in the new RPM matches the content in this ticket as expected. +1 # wget https://mirrors.edge.kernel.org/centos/8-stream/BaseOS/x86_64/os/Packages/dnf-automatic-4.2.17-3.el8.noarch.rpm # rpm2cpio dnf-automatic-4.2.17-3.el8.noarch.rpm | cpio -idmv # cat ./usr/lib/systemd/system/dnf-automatic.timer [Unit] Description=dnf-automatic timer # See comment in dnf-makecache.service ConditionPathExists=!/run/ostree-booted Wants=network-online.target [Timer] OnCalendar=*-*-* 6:00 RandomizedDelaySec=60m Persistent=true [Install] WantedBy=multi-user.target Luca, I'm not entirely sure what you're asking for and also the versions of dnf-automatic for the apssing and failing tests confuse me, the old one is failing and the new one is passing. If you're asking for how to fix the test, the test is obviously testing for the contents of the timer files, so you can just update the test with the new contents of the file (for whatever is such a test good for). Cheers. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:1823 |