And that is actually how it's supposed to work. The last thing you want is unattended-upgrades silently restarting services (read: which can fail the start bit)

And that is actually how it's supposed to work. The last thing you want is unattended-upgrades silently restarting services (read: which can fail the start bit) behind your back. If the upgrade fails to restart nginx properly, your customers won't be seeing the pages they need to. If the upgrade fails to start sshd, you have just lost access to the system(s) you would need to fix. Plus my personal favourite: if the upgrade-and-restart breaks your message broker, EVERYTHING is on fire. In most non-orchestrated, non-cloud-native environments the right way for security upgrades is to have them available, preinstalled and configured, but not yet active. What you do need is monitoring to tell you these things are waiting so you can apply them as soon as feasible. Although to be fair, once you have orchestration, robust zero-downtime rollouts and a good CI to rebuild new versions as upgrades become available... that's a different story.