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.

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.

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.

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"

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.

This still applies to Fedora 28.

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.

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.

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.

This is still current in Fedora 30.

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.

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.

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

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.

Still applies to Fedora 34.

FWIW, I took would like a "any updates == reboot" option.  I do believe there is a valid use case that affects specific kinds of servers.  This opens the door to users wanting selective reboots, but that can be another issues on another day.

I'd add that even some simple conditioning, like "reboot if any updates applied // reboot if updates that clear this regex applied // don't reboot" could be an intermediate step.  But the MVP is still just "reboot if updates applied."

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
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
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 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 Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Still applies to F36.

Do you have any opinion about a simple "always reboot" option at least? Quite frankly, dnf-automatic is dangerous without that, as you can never be sure that updates actually take effect, or to disrupt the currently running services.

For comparison, Fedora CoreOS' ignition service auto-reboots after installing an updated image. Doing that by default is *the right thing*. I don't mind a config option to opt out of that, but most people shouldn't know about that.

Personally, I am surprised that this functionality is still not there.

I've started work on this feature here: https://github.com/rpm-software-management/dnf/pull/1879.

There's a "reboot = when-changed" setting that triggers a reboot after any packages are upgraded, and a "when-needed" setting that triggers a reboot only when certain important packages are upgraded, like the kernel and systemd. The "when-needed" setting essentially takes the same approach as `dnf needs-restarting`, but it may be more reliable since we don't have to guess whether a certain process was restarted since upgrading---rather, the reboot is triggered directly following the upgrade.

There is also a `reboot_command` setting that allows customizing the command used to trigger a reboot, e.g. you could specify `reboot_command = "shutdown -r +5 'rebooting soon!'"` to add a delay and a wall message.

Very cool, thanks Evan! Looking forward to this.

https://github.com/rpm-software-management/dnf/pull/1879 has been merged! See the docs for the `reboot` and `reboot_command` options in https://github.com/rpm-software-management/dnf/blob/master/doc/automatic.rst.

The feature is included in dnf-4.15.0 (released version)