6

I have been trying to find a straight answer for this but I can't find it anywhere. Does unattended upgrades for security patches restart services automatically? If so, any way to prevent it from doing so for some packages where is may be very disruptive like postgresql for example? And, is there anywhere in the logs where you can see when a service was restarted last?

Ulukai
  • 385
  • 3
  • 13
  • It's up to the package to restart services, not unattended-upgrades. See http://askubuntu.com/questions/74061/install-packages-without-starting-background-processes-and-services for a related problem. – muru May 21 '16 at 09:49
  • Thanks, but that answer would not apply to unattended upgrades, even if I did apply to unattended upgrades, it would to all packages, I was looking to apply this to only some packages. – Ulukai May 22 '16 at 09:13

1 Answers1

4

To answer this question, it first is important to clarify that unattended-upgrades is a service which basically runs an "apt upgrade", automatically, on your behalf. If you've ever upgraded a package, you'll notice that many of them trigger actions as part of the process; for instance, if you upgrade rsync you'll notice that the daemon is restarted:

Setting up rsync (3.1.0-2ubuntu0.2) ...
   * Restarting rsync daemon rsync                                 [ OK ]

Generally, well-written debian packages which contain daemons (in other words, running services) will restart those daemons as part of the upgrade; if it doesn't happen for a package you care about, do file a bug (and if you can, provide a fix).

There is an important case where this doesn't happen: when instead of upgrading the service itself, you upgrade a system package which it depends on. One example which comes to mind is openssl, which is used by many services which implement SSL support. For those, a manual restart of the service is required, and if you don't know how many or which ones need to be restarted, a reboot solves the problem.

To avoid certain packages from being upgraded, add packages to the Unattended-Upgrade::Package-Blacklist config stanza; see the answer to Can I configure Unattended Upgrades to not upgrade packages that require a reboot? for an example of the syntax.

Finally, on the topic of upgrades, it's worth plugging the canonical-livepatch service which provides free, unattended, live upgrades for critical security fixes to the kernel. If you haven't checked it out, you should.

Community
  • 1
kiko
  • 358
  • 1
  • 12
  • 1
    Note to self: still need an answer on how to prevent restarts, and logs which indicate upgrade/restart. – kiko Oct 25 '16 at 06:11
  • I installed Livepatch, but was unsure whether I should change Unattended-Upgrade::Automatic-Reboot to false in /etc/apt/apt.conf.d/50unattended-upgrades. Does it matter once Livepatch is installed? – Darryl Nov 03 '16 at 04:34
  • canonical-livepatch only covers the kernel, and only a subset of changes to it (security issues, basically), so you should still be prepared to reboot periodically. However, whether or not to let unattended-upgrades handle that reboot for you is situation-specific -- are you okay with your machine being rebooted automatically, or do you prefer to be the one doing it? – kiko Dec 04 '16 at 16:53
  • "There is an important case where this doesn't happen" .. can we rely on unattended upgrades to reboot the system in these cases? (Assuming we have unattended upgrades set up to do reboots). I may just set my server up to also reboot once per (day? week?) as an extra precaution. – Kevin Wheeler Jul 22 '22 at 17:41