Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1491190 - Add automatic reboot to dnf-automatic
Summary: Add automatic reboot to dnf-automatic
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 34
Hardware: All
OS: All
unspecified
unspecified
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1488524
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-13 09:26 UTC by Martin Pitt
Modified: 2021-04-29 18:09 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)

Description Martin Pitt 2017-09-13 09:26:10 UTC
Description of problem:

The whole point of dnf-automatic is to not worry about updates and apply them automatically. However, a lot of updates (kernel, basic libraries, network-exposed services) need restarts of one or possibly many services/running processes after installing them. On non-mission critical servers, cloud instances, or appliances it would be best to simply let them automatically reboot after applying updates.

E. g. Debian's/Ubuntu's unattended-upgrades package (the counterpart of dnf-automatic) has an "Unattended-Upgrade::Automatic-Reboot" option which reboots *if* there was an update that required a reboot.

For dnf-automatic there could be a similar option in /etc/dnf/automatic.conf, which would then do something like

  if dnf needs-restarting; then
      shutdown -r +5m "rebooting after applying package updates"
  fi


Version-Release number of selected component (if applicable):

dnf-automatic-2.6.3-1.fc26.noarch

Comment 1 Martin Pitt 2017-09-13 09:30:39 UTC
https://fedoraproject.org/wiki/AutoUpdates#Alternative_methods also mentions "auter" which can do this, but it seems to me that dnf-automatic is the "official" way of applying updates, so for integrating automatic updates into Cockpit (https://github.com/cockpit-project/cockpit/wiki/Feature:-System-Updates-for-dnf,-yum,-apt-hosts) I'd rather stick with that.

Cockpit could write a dnf-automatic-install.service.d/reboot.conf with an `ExecStartPost=` command like the above, but normally it's not Cockpit's place to change the behaviour of system software like that - it should just drive those through the official configuration channels.

Comment 2 Martin Pitt 2017-09-13 10:22:23 UTC
It seems `dnf needs-restarting` isn't capable enough to reliably detect situations where a reboot is necessary yet. I upgraded "dbus", and "dnf needs-restarting" is empty and exits with 0, and this is definitively a case where the running daemon is old (compared to the upgraded package). Until we have a reliable and fast method (i. e. tracer isn't always installed and can take very long), the option should just always reboot if there were any updates, to be on the safe side.

Comment 3 bugzilla 2017-09-19 01:04:49 UTC
Maybe `tracer` https://github.com/FrostyX/tracer is better in detecting situations where a reboot is necessary.
Futhermore https://github.com/agross/dnf-automatic-restart could be interesting regarding this feature request.

Nevertheless I would also appreciate to have this functionality built into dnf-automatic.

Comment 4 Martin Pitt 2017-09-19 15:50:54 UTC
Even just a simple "reboot if there has been any update" functionality would make things a lot easier, as it's annoyingly hard to find out this fact from outside; the only place (that I found) that carries that information is the journal from the service, and pretty much every string in there gets localized.

So my hack for figuring out if dnf-automatic-install.service actually installed any upgrade is this:

# /etc/systemd/system/dnf-automatic-install.service.d/autoreboot.conf
[Service]
ExecStartPost=/bin/sh -ec "systemctl status --no-pager --lines=100 dnf-automatic-install.service| grep -q ===========$$ && shutdown -r +5 rebooting after applying package updates"

Comment 5 Fedora End Of Life 2018-05-03 07:52:36 UTC
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 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 '26'.

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 26 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.

Comment 6 Martin Pitt 2018-05-03 07:58:55 UTC
This still applies to Fedora 28.

Comment 7 Paolo Gigante 2018-08-06 18:16:07 UTC
Hi Martin,

Assessing if a server needs a reboot after patches have been applied is not always straight forward. There are quite a few separate assessments that need to be made to accurately determine if a reboot is really required. Auter does have a configuration option to automatically reboot servers after patches have been applied however with auter, the assessment is, as you mentioned above, if any patches are applied a reboot will be carried out. 

With auter there has intentionally been multiple stages where custom scripts can be executed. This leaves the possibility of adding a post-apply script to do an assessment and reboot the server based on that assessment. See https://github.com/rackerlabs/auter/tree/develop/contrib/conditionalReboot for details on that. Note that this is not an absolute and all-encompassing assessment script but it does cover some of the basics which seem to be meet your requirement.

I would also like to point out that dnf-automatic is essentially just a wrapper around dnf (as yum-cron is to yum) which is what auter is too. Looking at the setup instructions for cockpit which you mentioned earlier (https://github.com/cockpit-project/cockpit/wiki/Feature:-System-Updates-for-dnf,-yum,-apt-hosts) this seems to simply schedule updates for the system with no specific requirements or customizations. This is easily achievable with auter. 

Back the the original spirit of this issue, it would be ideal if dnf itself could assess if a reboot is required and either inform the user or optionally automatically reboot the server. The main purpose of dnf-automatic is to automate dnf updates which should also offer that functionality but alas it does not so:

 +1 to the request 

but in the mean time, auter seems to be a very reasonable workaround / solution to your situation.

Comment 8 Martin Pitt 2018-08-14 07:22:30 UTC
Thanks Paolo. auter isn't available in RHEL downstream, so for that it would still be good to have a solution in dnf-automatic. Note that I'm not asking for logic to determine *if* a reboot is necessary, just to always do it after applying updates. This covers the main use cases of (mostly) unattended servers, as they often can (and should be able to) be rebooted. If not, then conditional automatic rebooting shouldn't be done either.

Comment 9 Ben Cotton 2019-05-02 19:43:41 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. 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 '28'.

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 28 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.

Comment 10 Martin Pitt 2019-05-03 05:53:35 UTC
This is still current in Fedora 30.

Comment 11 Ben Cotton 2020-04-30 20:26:22 UTC
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-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 '30'.

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 30 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.

Comment 12 Martin Pitt 2020-05-03 16:17:08 UTC
I just checked dnf-automatic in Fedora 32, and there's still no option to automatically reboot after installing updates. So this is still current.

Comment 13 iolo 2020-12-12 18:58:21 UTC
The feature page for offline system updates [1] says "Replacing libraries and files while the OS is running can cause problems ranging from application crashes to inconsistent system states where processes are using different versions of a library at the same time." Given this, it seems to me like the functionality of dnf-automatic to only install updates but not reboot afterwards is somewhat lacking. I can install updates automatically, but I still have to log in to the server all the time to check if an update has been applied, and then reboot manually. I might as well not be installing updates automatically at all, only installing them whenever I log in to the server anyway, which makes dnf-automatic redundant.

A conceptually simple switch to always reboot after applying updates would be enough to fix this, though I do not know how difficult that is to implement technically. For more production-oriented needs such a switch may be inadequate, but I am only a home user hosting a personal website and some other minor stuff. The effort of having to log in to the server all the time is a greater burden than the burden of fixing something in the unlikely event that an update and reboot happens to break it.


[1] https://fedoraproject.org/wiki/Features/OfflineSystemUpdates

Comment 14 Fedora Program Management 2021-04-29 15:53:37 UTC
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
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 '32'.

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 32 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.

Comment 15 Martin Pitt 2021-04-29 18:09:43 UTC
Still applies to Fedora 34.


Note You need to log in before you can comment on or make changes to this bug.