When you manage Ubuntu servers in production, package updates are never just about installing new versions. The real risk is what happens after the upgrade finishes: stale daemons keep running with old shared libraries, a database service gets restarted at the wrong time, or an unattended update quietly changes system state during peak traffic. That is exactly where needrestart earns its place in the admin toolbox. Ubuntu ships it in server images and uses it at the end of APT transactions so the system can detect services, containers, kernels, and microcode that may need a restart after updates.

On Ubuntu 26.04 LTS, the practical goal is not merely “install the package.” The important part is understanding how needrestart behaves, how it integrates with apt and dpkg, and how to tune it so it helps rather than surprises you. In a busy environment, a restart prompt at the wrong moment can be annoying; an automatic service restart during a traffic spike can be expensive. On the other hand, ignoring stale libraries after security updates is also a bad habit. The best admin workflows sit in the middle: controlled, observable, and repeatable. That is the mindset this guide follows.

What Needrestart Does

needrestart checks whether daemons, containers, the kernel, or CPU microcode should be restarted after package upgrades, especially when a shared library has been replaced underneath a running process. It is fully integrated into APT/dpkg hooks and is meant to answer a simple operational question: “Which running components are still using outdated code right now?”

That sounds small, but it matters a lot in production. A patched package does not automatically mean the running service is safe; if the service still has old memory mappings, it may remain exposed until restarted. The tool is also useful during maintenance windows because it gives you a clear list of what actually needs attention instead of forcing a full reboot out of caution.

Installation Steps

Installing needrestart on Ubuntu 26.04 LTS is straightforward with APT. In most cases, a standard repository install is enough because Ubuntu provides the package and keeps it integrated with the system update flow.

sudo apt update
sudo apt install needrestart

After installation, verify the package is present:

dpkg -l needrestart
needrestart --version

If you are working on a server that already receives regular updates, the package may already be installed. Ubuntu’s server images ship it by default in many cases, and the post-upgrade hooks are designed to use it automatically. That means you do not need to create any custom service or systemd unit; the package is designed to work as part of the update pipeline.

First Check After Install

Once installed, run a manual check to see what the system thinks needs attention. The simplest non-interactive mode is useful for scripts and quick audits.

sudo needrestart -b

For a more human-readable check, use the standard I/O interface:

sudo needrestart -u NeedRestart::UI::stdio -r l

The -r l mode lists what needs restarting without actually restarting anything, which is the safest option when you are first validating behavior on a production host. This is the mode I would reach for on a server that just finished patching during business hours, because it gives visibility without changing state.

Apt Integration

The most important thing to understand is that needrestart is not just a standalone command. It is wired into APT transactions so it can run after installs, upgrades, and removals, and also during unattended upgrades. That integration is what makes it useful in day-to-day operations, because you do not have to remember to run it manually after every patch cycle.

In Ubuntu 24.04, Ubuntu changed the default behavior so affected services are restarted directly in more cases, rather than waiting for a prompt in interactive sessions. That means on modern Ubuntu releases, you need to think of needrestart as part of update policy, not just a diagnostic tool. The same operational logic carries forward for Ubuntu 26.04 LTS: patching and restart behavior should be planned together, not treated as separate events.

Service Restart Modes

needrestart supports different restart modes, and those modes matter when you are trying to balance safety and uptime. The practical modes you will see most often are list-only, interactive, and automatic behavior controlled through APT integration.

A common safe workflow looks like this:

sudo needrestart -u NeedRestart::UI::stdio -r l

If you want to review and then act manually, this is a good operational pattern:

sudo systemctl restart nginx
sudo systemctl restart php8.3-fpm

The point is to keep restart timing under your control. That is especially useful for web stacks, databases, queue workers, and anything that is sensitive to brief interruption. If your site has traffic spikes, a surprise service restart at the wrong moment is exactly the sort of thing that creates false outages and noisy alerts.

Configuration Basics

The main config files are typically located under /etc/needrestart/ and drop-in snippets can be placed in /etc/needrestart/conf.d/. This is where you tune service behavior, blacklist or override restart decisions, and make the tool fit your environment.

A simple drop-in file can be created like this:

sudo nano /etc/needrestart/conf.d/local.conf

Example to prefer list-only behavior:

$nrconf{restart} = 'l';

This tells needrestart to report what should restart without making the restart automatic. That is useful for admins who want an explicit maintenance workflow, or for environments where application owners must approve restarts before they happen.

Excluding Critical Services

Sometimes you do not want a specific service to be restarted automatically, even if its libraries changed. Ubuntu’s guidance is to prefer override_rc for service-specific behavior rather than broadly disabling restarts. This gives you fine-grained control and avoids turning off a security mechanism globally.

Example drop-in:

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

That pattern is especially useful for services that are extremely latency-sensitive or that coordinate state in a way that makes mid-day restarts risky. In practice, I would use this only for well-understood exceptions, not as a default habit.

Production Use Cases

On a typical web stack, needrestart is most valuable after library updates that affect nginx, PHP-FPM, database connectors, Redis clients, or application workers. If you run WordPress at scale, for example, a package upgrade may replace a library that php-fpm or background workers are still holding in memory. The tool helps you spot that state before the next request path exposes it.

It is also useful for container-heavy hosts. The package can detect required restarts for containers such as Docker and LXC in supported cases. That matters if you run mixed workloads on the same host and want a single audit pass after patching. For sysadmins, this is one of those tools that looks minor on paper but saves a lot of guesswork in real operations.

Troubleshooting Errors

The most common issue is confusion about whether needrestart is installed, enabled, or behaving as expected. If the command is missing, reinstall it with APT and recheck the package state.

sudo apt install needrestart
sudo needrestart -b

If you expect a service to be listed but it is not, check whether the service was already restarted, whether it is blacklisted, or whether the process is not using an affected library anymore. If you are customizing restart behavior, make sure your drop-in files are in /etc/needrestart/conf.d/, not a guessed path elsewhere. That path detail matters more than people think, because a typo here means your policy silently does nothing.

Safe Operational Workflow

A clean maintenance workflow on Ubuntu 26.04 LTS usually looks like this:

1. Patch during a defined maintenance window.
2. Run apt upgrade or your automation job.
3. Review needrestart output.
4. Restart only the affected services you actually intend to touch.
5. Validate application health, logs, and upstream behavior.

That sequence is boring, and that is exactly why it works. The less surprising your restart policy is, the easier it is to keep production stable. A good admin workflow reduces noise in monitoring, avoids unnecessary downtime, and creates a predictable audit trail.

Performance and Security

From a security angle, needrestart is valuable because it helps close the gap between “patched package installed” and “running service is actually using the patched code.” That gap is easy to forget when updates are automated. It is also why security-conscious environments should not disable the tool globally without a very clear reason.

From a performance perspective, restart timing matters just as much as restart necessity. On systems with high CPU load, limited RAM, or heavy disk I/O, a service restart may temporarily increase latency or trigger cache rebuilds. On network-sensitive services, the restart may also break keepalive sessions or force client reconnection. That is why planning matters: the tool tells you what to restart, but your operations process decides when.

Useful Admin Commands

A few commands are worth keeping in your daily toolkit:

sudo needrestart -b
sudo needrestart -u NeedRestart::UI::stdio -r l
systemctl status nginx
journalctl -u nginx -n 100 --no-pager
apt list --upgradable

If you are tracking a larger maintenance cycle, combine them with standard diagnostics like top, htop, free -h, df -h, iostat, ss -tulpn, and journalctl. That gives you a full picture of whether a restart is actually safe at that moment. The best admins do not just restart services; they verify that the system can absorb the restart cleanly.