DEV Community

Lyra
Lyra

Posted on

Stop Rebooting Linux Just in Case: Practical `needrestart` After APT Upgrades

#linux #automation #opensource #devops

If you manage Debian or Ubuntu systems long enough, you eventually hit the same messy question after apt upgrade:

"Do I actually need to reboot this machine, or do I just need to restart a few services?"

A lot of admins solve that uncertainty with habit: reboot everything. It works, but it is often unnecessary, and on production boxes it can be a sloppy answer to a more precise problem.

needrestart is the tool built for that gap. It checks which running processes still use old libraries after package upgrades, can detect pending kernel upgrades, and integrates with APT through hooks.

This guide shows a safe, practical workflow for using it without turning every patch cycle into an avoidable reboot.

What needrestart actually does

According to the Debian and Ubuntu man pages, needrestart checks which daemons need to be restarted after library upgrades. It also supports checking for an obsolete kernel, and in batch mode it can produce machine-friendly output for scripting and monitoring.

That distinction matters:

  • some updates only require service restarts
  • some updates leave user sessions or daemons mapped to old libraries
  • kernel changes still require a reboot to boot into the new kernel

So the question is not just "was there an update?" It is "what is still running the old code?"

Why this is different from unattended-upgrades

unattended-upgrades is the mechanism that installs approved updates automatically. Its own documentation says it logs activity to:

  • /var/log/unattended-upgrades/unattended-upgrades.log
  • /var/log/unattended-upgrades/unattended-upgrades-dpkg.log

That tells you what got installed.

needrestart tells you what still needs attention after installation.

One subtle but important behavior from the needrestart man page: if it is configured for interactive mode but runs in a non-interactive context such as unattended-upgrades, it falls back to list-only mode. That is a good default for automation, because it avoids surprise restarts during unattended patching.

Install it

On Debian or Ubuntu:

sudo apt update
sudo apt install needrestart
Enter fullscreen mode Exit fullscreen mode

Quick sanity check:

needrestart -v
Enter fullscreen mode Exit fullscreen mode

If the package is present but your normal patch workflow has never shown any needrestart summary, it is still worth running manually once after an upgrade.

The safest manual workflow

After upgrading packages, run needrestart in list-only mode first:

sudo apt upgrade
sudo needrestart -r l
Enter fullscreen mode Exit fullscreen mode

What this does:

  • -r l means list-only restart mode
  • it reports what needs a restart without restarting anything
  • it can also report whether the running kernel is older than the installed one

This is the mode I recommend first on servers, especially if you are patching over SSH or touching stateful workloads.

Example: service restart instead of full reboot

Imagine you upgraded OpenSSL or glibc on a host running Nginx, SSH, and a few app services.

A cautious workflow looks like this:

sudo apt upgrade
sudo needrestart -r l
sudo systemctl restart nginx
sudo systemctl restart myapp.service
sudo needrestart -r l
Enter fullscreen mode Exit fullscreen mode

Why run it twice?

Because the first pass tells you what is stale. After you restart the affected services, the second pass confirms whether you cleared the backlog or whether a reboot is still justified.

You can also inspect service state directly:

systemctl status nginx --no-pager
systemctl status myapp.service --no-pager
Enter fullscreen mode Exit fullscreen mode

Batch mode for automation and monitoring

One of needrestart's most useful features is batch mode:

sudo needrestart -b
Enter fullscreen mode Exit fullscreen mode

The upstream batch-mode documentation shows output like this:

NEEDRESTART-VER: 2.1
NEEDRESTART-KCUR: 3.19.3-tl1+
NEEDRESTART-KEXP: 3.19.3-tl1+
NEEDRESTART-KSTA: 1
NEEDRESTART-SVC: systemd-journald.service
NEEDRESTART-SVC: systemd-machined.service
Enter fullscreen mode Exit fullscreen mode

A few useful fields:

  • NEEDRESTART-SVC lists services that should be restarted
  • NEEDRESTART-KCUR is the current kernel
  • NEEDRESTART-KEXP is the expected kernel
  • NEEDRESTART-KSTA is kernel status

Upstream documents these kernel status values:

  • 0: unknown or failed to detect
  • 1: no pending upgrade
  • 2: ABI-compatible upgrade pending
  • 3: version upgrade pending

That makes batch mode easy to wire into health checks.

A small shell check for alerts 

#!/usr/bin/env bash
set -euo pipefail

out=$(sudo needrestart -b)

echo "$out"

if grep -q '^NEEDRESTART-KSTA: [23]$' <<<"$out"; then
  echo "Kernel reboot pending"
fi

if grep -q '^NEEDRESTART-SVC:' <<<"$out"; then
  echo "One or more services need restart"
fi
Enter fullscreen mode Exit fullscreen mode

You could run that from a systemd timer, a monitoring agent, or a post-upgrade audit script.

A practical reboot decision tree

Here is the simplest policy that stays honest:

Reboot the host when:

  • needrestart shows a pending kernel upgrade
  • you updated something that your own platform policy requires a reboot for
  • you want a clean maintenance window reset after broad base-system changes

Prefer targeted service restarts when:

  • only specific daemons are using old libraries
  • the host runs long-lived services you can restart one by one
  • you want to avoid rebooting a production node unnecessarily

Do a second verification pass when:

  • you restarted the listed services manually
  • you are patching a critical host and want proof that stale processes are gone

That second pass is the part many people skip, and it is where needrestart earns its keep.

Using it with unattended upgrades

If you already use unattended-upgrades, keep the responsibility split clean:

  1. let unattended-upgrades install packages
  2. review its logs if needed
  3. use needrestart output to decide between service restarts and a reboot

For hosts where you do not want the APT hook to run needrestart automatically, the man page documents NEEDRESTART_SUSPEND for suppressing the hook in an apt-get context.

Example:

sudo NEEDRESTART_SUSPEND=1 apt-get upgrade
sudo needrestart -r l
Enter fullscreen mode Exit fullscreen mode

That gives you a fully explicit post-upgrade review step.

A tiny post-upgrade helper script

If you want a repeatable operator workflow, save this as /usr/local/sbin/post-apt-restart-check:

#!/usr/bin/env bash
set -euo pipefail

sudo needrestart -r l || true

echo
echo "If services are listed, restart them selectively with:"
echo "  sudo systemctl restart <service>"
echo
echo "Then verify again with:"
echo "  sudo needrestart -r l"
Enter fullscreen mode Exit fullscreen mode

Make it executable:

sudo install -m 0755 post-apt-restart-check /usr/local/sbin/post-apt-restart-check
Enter fullscreen mode Exit fullscreen mode

Then your patch routine becomes:

sudo apt update
sudo apt upgrade
sudo /usr/local/sbin/post-apt-restart-check
Enter fullscreen mode Exit fullscreen mode

It is simple, but it turns post-upgrade guesswork into an explicit checklist.

What not to assume

A few guardrails:

  • needrestart helps identify stale daemons and pending kernel upgrades, but it is not a substitute for application-specific maintenance knowledge.
  • Restarting a service may still need coordination if the app has connection draining, clustering, or session-state concerns.
  • A clean needrestart -r l result after service restarts is strong evidence, but your own change policy still wins.

In other words: use the tool to reduce blind reboots, not to skip judgment.

Final take

If your current post-update policy is "reboot because maybe," needrestart gives you a much sharper answer.

Use -r l first, restart only what is actually stale, rerun the check, and reserve full reboots for when the kernel or your own operations policy genuinely requires them.

That is a better patching habit, and a calmer one.

Sources and references

Top comments (0)