Description of problem: a desktop system which is hibernated during unused time will receive only delayed updates via dnf-automatic timer, because it looks like only the active time of the system will be counted, not the absolute delta Version-Release number of selected component (if applicable): dnf-automatic-4.0.4-2.fc29.noarch How reproducible: always Steps to Reproduce: 1. install dnf-automatic 2. dnf-automatic-install.timer 3. wait and monitor timer status Actual results: check on Sunday systemctl list-timers *dnf-* NEXT LEFT LAST PASSED UNIT ACTIVATES Sun 2018-11-11 18:14:11 CET 53min left Sun 2018-11-11 17:14:10 CET 6min ago dnf-makecache.timer dnf-makecache.service Mon 2018-11-12 07:57:50 CET 14h left Sat 2018-11-10 10:37:33 CET 1 day 6h ago dnf-automatic-install.timer dnf-automatic-installer.service check on Monday (system was hibernated during the night): systemctl list-timers *dnf-* NEXT LEFT LAST PASSED UNIT ACTIVATES Mon 2018-11-12 08:58:18 CET 59min left Mon 2018-11-12 07:58:17 CET 34s ago dnf-makecache.timer dnf-makecache.service Mon 2018-11-12 15:37:57 CET 7h left Sat 2018-11-10 10:37:33 CET 1 day 21h ago dnf-automatic-install.timer dnf-automatic-install.service Next execution time of automatic-install timer jumped from Mon 2018-11-12 07:57:50 CET to Mon 2018-11-12 15:37:57 CET Expected results: No such jump Additional info: In worst case, a short used and then hibernated system will receive update far too late.
I'm afraid, this is the nature of the monotonic systemd timers (OnUnitInactiveSec we are using here is monotonic). See man systemd.timer: [...] These are monotonic timers, independent of wall-clock time and timezones. If the computer is temporarily suspended, the monotonic clock stops too. [...]
ok, thank you for explanation, then imho the wrong kind of timer is used because security updates pushed to stable should be installed next also on computers which are usually not running 24 hours like desktop systems behave. either adding a realtime timer in parallel or having a special timer which executes a during suspend/hibernate last missed would be the far better choice.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This has been resolved by switching to realtime timers in dnf-automatic here: https://github.com/rpm-software-management/dnf/pull/1521
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.