10

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
  • 425
  • 1
  • 6
  • 14

2 Answers2

5

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
  • 378
2

The answer for LTS 22 and 24 is: depends on your configuration of needrestart.

You can poke this command yourself:

needrestart --help

And it is integrated into apt, and of course works with unattended-upgrades.

Refer to upstream docs for further details.

I'll give an example.

Here I have something called keter.service, and have configured an exemption for it to not get autorestarted on libc upgrades. The exemption works like this:

$ sudo apt upgrade
[...]
Processing triggers for libc-bin (2.39-0ubuntu8.3) ...
Scanning processes...                                                                                                                                                                       
Scanning candidates...                                                                                                                                                                      
Scanning linux images...

Pending kernel upgrade!
Running kernel version:
  6.8.0-1014-aws
Diagnostics:
  The currently running kernel version is not the expected kernel version 6.8.0-1017-aws.


Restarting the system to load the new kernel will not be handled automatically, so you should consider rebooting.


Restarting services...
 systemctl restart acpid.service atop.service atopacct.service chrony.service cron.service fwupd.service irqbalance.service multipathd.service pmcd.service pmie.service pmie_farm.service pmlogger.service pmlogger_farm.service pmproxy.service polkit.service rsyslog.service site24x7monagent.service snapd.service ssh.service systemd-journald.service systemd-networkd.service systemd-resolved.service systemd-udevd.service udisks2.service


Service restarts being deferred:
 /etc/needrestart/restart.d/dbus.service
 systemctl restart getty@tty1.service
 systemctl restart keter.service
 systemctl restart networkd-dispatcher.service
 systemctl restart serial-getty@ttyS0.service
 systemctl restart systemd-logind.service
 systemctl restart unattended-upgrades.service


No containers need to be restarted.


User sessions running outdated binaries:
 ulidtko @ session #2: tmux: server[4652]
 ulidtko @ session #79023: apt[4092243], sshd[4075339,4075629]
 ulidtko @ user manager service: bash[4653,4715,4906], systemd[3645]


No VM guests are running outdated hypervisor (qemu) binaries on this host.

See the keter.service item under Service restarts being deferred ?

That's achieved by placing a config file any-name-you-like-ending-with.conf under /etc/needrestart/conf.d/ with the content:

$nrconf{override_rc} {qr/keter[.]service/} = 0;

That's in Perl syntax, and configures an override for a systemd service matched by a regex.

ulidtko
  • 5,988