`needrestart` changes in Ubuntu 24.04: service restarts

Foundations
1

needrestart changes in Ubuntu 24.04: service restarts

We have made significant changes to the default behavior of needrestart in Ubuntu during the Noble Numbat cycle. This post describes those changes, the rationale behind them, and how to adjust your systems to deal with them.

What is needrestart, exactly?

needrestart is a tool that probes your system to see if either the system itself or some of its services should be restarted. That last part is the one of interest in this document. Notably, a service is considered as needing to be restarted if one of its processes is using a shared library whose initial file isn’t on the system anymore (for instance, if it has been overwritten by a new version as part of a package update).

We ship this tool in our server images, and it is configured by default to run at the end of APT transactions, e.g. when doing apt install/upgrade/remove or during unattended-upgrades. Most of our modifications only affect needrestart in that context.

New behavior

Previously, needrestart behaved differently depending on the context in which apt was invoked. If it was called in an interactive context like a shell prompt or a GUI frontend, it would prompt you with a list of affected services, usually defaulting to restarting most of the listed daemons. Once the user acknowledged the prompt, the tool would restart the selected services.

A noninteractive context, such as invoked from a script, would instead result in needrestart listing the affected services on the standard output and nothing more.

We have changed both of these behaviors. The tool now behaves the same in both cases by directly restarting the affected services (as was previously the default in the interactive case). Any affected service that hasn’t been restarted is also listed on the standard output.

Rationale

If we update a library on a stable series, there is a reasonable chance it is to fix a security issue in that library. Notably, unattended-upgrades in its default configuration only installs updates from the security pocket.

Now, having a fixed package is good, but that doesn’t mean that the system itself is secure. As long as there are services using the outdated library, they are still vulnerable.

Furthermore, loading multiple shared objects from different versions of a given package can very easily lead to crashes and data loss.

Troubleshooting

If this new behavior causes issues, try one of the following:

Prevent a single service from being restarted

If the service that shouldn’t be restarted is from a Ubuntu package, file a bug so that we can change the default configuration to avoid it.

Alternatively, you can handle it yourself. Ideally, you should modify your service to gracefully support being restarted. However, in the event it isn’t possible or relevant, you can tell needrestart not to automatically restart a given service by adding a regexp matching its service file to $nrconf{override_rc} in/etc/needrestart/needrestart.conf.

It can also be done by dropping a Perl one-liner in a file in /etc/needrestart/needrestart.conf.d/, for example:

echo '$nrconf{override_rc}{qr(^mycompany-(dispatch|worker)\.service$)} = 0;' | sudo tee /etc/needrestart/conf.d/mycompany.conf

Restore the previous behavior

You can permanently restore the previous behavior by editing /etc/apt/apt.conf.d/99needrestart to remove the -m u CLI option.

A more ephemeral approach can be taken by forcing the needrestart UI, e.g.

NEEDRESTART_UI=NeedRestart::UI::Debconf sudo apt upgrade
4 Likes
2

Thank you for working on this!

One question that I have on reading the recent ubuntu-devel-discuss thread is: what’s the recommended way of disabling service restarts for all packages? Is this to edit /etc/apt/apt.conf.d/99needrestart as you described, or something else? Because the former way doesn’t seem like it would really capture the intent and the default behaviour for that path might be something that changes again in a future release.

I ask because in a production server environment it is often the case that the operators or tooling intended for such use wish to take over all update-related automated functions, including automatic updates and service restarts, and I think there should be a single place where this is documented without needing to be aware of the necessary configuration changes on a per-component basis (unattended-upgrades, dpkg, apt, policy-rc.d, etc).

For example, we have a nascent area in the server guide under Managing Software that would be a good place to put this information.

3

It is indeed important in production server environments to have control over the timing of service restarts for updates.

However, the correct layer at which to manage this is to control when the updates are installed, not to change the behavior of the system to not restart services on package update.

Without needrestart, package updates will already restart services and therefore the installation of package updates should be done during a maintenance window. The only difference with needrestart is that we are now more correctly restarting services affected by a security update to a library, whereas without needrestart we are not doing so; and as a result we can now provide better assertions to users about the security state of their running system and whether a system restart is required.

So just as there is no supported way to blanket disable the restart of services from package maintainer scripts on upgrade, there should be no supported way to blanket disable the restart of services by needrestart.

1 Like