needrestart reads /proc to tell you which daemons a library upgrade broke

Installing means the hook scripts call it after every package operation

The deployment model is a set of hook scripts rather than a daemon. There are hook scripts in the `ex/` directory, to be used with apt and dpkg, and the scripts will call needrestart after any package installation or upgrade, so the check happens at the moment the libraries change. The Makefile is what puts those pieces on the system, and its two build steps are the ones a packager runs:

	cd perl && perl Makefile.PL PREFIX=$(PREFIX) INSTALLDIRS=vendor
	cd perl && $(MAKE) install

The `all` target depends on `mo-files`, because the interface is translated, and the install step then copies the hook scripts into `/etc/needrestart/hook.d/`, the configuration into `/etc/needrestart/`, the notify and restart drop-ins into their own directories, and the `needrestart` program itself into `/usr/sbin/`. The apt and dpkg integration is conditional on those tools being present, and the Makefile guards it with a `command -v apt-get` test. The polkit action file goes to `/usr/share/polkit-1/actions/`, and the two helper scripts for the microcode and kernel detectors go to `/usr/lib/needrestart/`.

The mechanism is comparing mapped objects against the files on disk

The problem is old and the approach is deliberately simple. needrestart checks which daemons need to be restarted after library upgrades, and it is inspired by checkrestart from the debian-goodies package. The data it works from is the process memory map. On Linux a running process exposes the shared objects it has loaded through `/proc/<pid>/maps`, and needrestart compares that against the current state of those files on disk. When a shared library has been replaced by an upgrade, the running process is still executing the old inode, and that difference is what needrestart reports. The documentation names the limitation of that source directly for kFreeBSD, where `/proc/<pid>/maps` does not show removed file links, so the tool has limited functionality on GNU/kFreeBSD. The consequence for the design is that needrestart is a detector of stale mappings rather than a resolver of declared dependencies, and the two are not the same thing.

systemd is used when present, and hooks cover everything else

The restart mechanism has two paths, and the choice between them is made at runtime. needrestart supports but does not require systemd, which has been available since v0.6. If systemd is used you should use libpam-systemd too, because if needrestart detects systemd it will assume that libpam-systemd is used and rely on cgroup names to work out whether a process belongs to a user session or to a daemon. If you do not use libpam-systemd you should set `$nrconf{has_pam_systemd}` to 0 in needrestart.conf, which is the kind of detail that only matters once something has gone wrong. If systemd is not available, or does not return a service name, needrestart uses hooks to identify the corresponding System V init script, and the shipped hooks support three package managers, dpkg, rpm and pacman. The `service` command is what runs the traditional System V init script. The repository root holds the `ex/` directory with the hook scripts used with apt and dpkg, and a `hooks/` directory that the Makefile copies into `/etc/needrestart/hook.d/` on installation.

Interpreters are scanned for stale source, which is the security-relevant part

Interpreters get their own detection path, and the reason is stated in the documentation in a way that matters. Interpreters not only map binary shared objects but also use plaintext source files, and the interpreter detection tries to check for outdated source files since they may contain security issues too. The scanner that came with needrestart 0.8 is explicitly called a heuristic and might fail to detect all relevant source files, and the shipped scanners are NeedRestart::Interp::Java, NeedRestart::Interp::Perl, NeedRestart::Interp::Python and NeedRestart::Interp::Ruby. The framing is the interesting part. When a Perl module is upgraded, the process running the old code does not have a stale shared object mapping in the usual sense, because the interpreter reads the source at run time and the running process keeps the old code in memory. A tool that only compared mapped objects would report nothing at all in that case, which is why the interpreter scanners exist and why the documentation describes them as a heuristic rather than an exact answer.

Containers can be detected but not always restarted

Since needrestart 2.1 the tool detects some container technologies, and the reason it does is a limitation rather than a feature. If a process is part of a container it might not be possible to restart it using Sys-V or systemd, because the init system inside the container is not the one the host uses. The implementation follows the same modular pattern as the rest of the project, with special Perl packages, NeedRestart::CONT::*, implementing the container detection and the restarting. The detectors that ship are NeedRestart::CONT::docker, NeedRestart::CONT::LXC and NeedRestart::CONT::machined. The separate file README.Cont.md holds the details. In practice this means a containerised daemon on a host is a case where needrestart can tell you that something is stale and still be unable to do anything about it, which is the more common outcome inside containers than the detection part.

Kernel and microcode get their own detectors

Two upgrade types sit outside the shared library case and have their own handling. The first is the kernel. needrestart 0.8 brought an obsolete kernel detection feature, and since needrestart 3.5 it is possible to filter kernel image filenames, which the documentation says is required on Raspberry Pi, with the details in README.raspberry.md. The second is processor microcode. A processor microcode update detection feature for Intel CPUs was added in needrestart 3.0, and since 3.5 the AMD CPU support has been added, documented in README.uCode.md. Both are cases where the file on disk has changed but the running system is executing the previous version, and a reboot is the only way to pick it up, so detection without a restart mechanism is the correct behaviour. The two helper programs the Makefile installs, `lib/iucode-scan-versions` and `lib/vmlinuz-get-version`, are the scripts behind these two features.

Batch mode, Nagios mode and pluggable frontends make the output consumable

The tool is not only interactive. needrestart can be run in batch mode to use the results within other programs or scripts, documented in README.batch.md, and there is also a nagios plugin mode in README.nagios.md. That distinction is the one that decides whether needrestart fits your environment. The interactive frontends are aimed at a human sitting at a package upgrade, and the debconf one in particular assumes a Debian-style flow where the question appears in the middle of an apt operation. The batch and Nagios modes are the ones that matter for automation, where the point is not to ask a question but to produce a finding that another program acts on, for example a monitoring check that goes red when a service is running against a replaced library. The configuration surface is also plural. The Makefile installs a whole tree of configuration directories, `conf.d`, `notify.d` and `restart.d` under `/etc/needrestart/`, alongside the main `needrestart.conf` and `notify.conf` files, so behaviour is split across drop-in directories rather than a single file. The user interface is separated from the detection logic, and the documentation describes the approach as modular, based on Perl packages providing the user interface. Two frontends are shipped. NeedRestart::UI::Debconf uses debconf, which is the Debian way of asking a question during a package operation, and NeedRestart::UI::stdio is a fallback using stdio interaction, so the tool still works on a system with no debconf. The Makefile shows the debconf integration being wired up, with a `po2debconf` step that converts `ex/debconf/needrestart.templates` into a `needrestart.templates` file under `/usr/share/needrestart/`, and only when `debconf` is present on the system, since the Makefile guards that block with a `command -v debconf` test. There is also a polkit action file copied into `/usr/share/polkit-1/actions/`, which is the piece that lets a desktop user authenticate for a privileged restart without a terminal password prompt.

Where a restart checker is the wrong tool

The limits follow from the mechanism. The first is that a mapping comparison is evidence, not proof. A process that has not mapped a replaced library is not affected, but a process that mapped it might tolerate the change, and the tool reports the mapping rather than the consequence. A database server that opened its shared memory segment before an upgrade is reported as needing a restart whether or not that particular mapping matters to it, so the output is a work list to review rather than a set of commands to run unattended. The second is the interpreter heuristic, which the documentation itself says might fail to detect all relevant source files, so a clean report on a Perl or Python service is weaker evidence than a clean report on a compiled daemon. The alternative to weigh against is a service manager that tracks its own dependencies, where a systemd unit that declares its library dependencies is restarted by the manager when the package changes. The difference in approach is that a declarative manager knows the dependency graph and can act on it, while needrestart infers the graph from the running system's memory and asks a human. On a system with systemd units that already declare their dependencies, needrestart adds a second, independent view of the same problem. On a system with a long tail of services whose units say nothing about their libraries, it is the only view there is.

Editorial conclusion

needrestart is worth wiring into your package hooks if you upgrade libraries on a machine with long-lived daemons, because it replaces the guesswork of remembering which services to bounce with a check that inspects what is actually mapped into running processes, and because the debconf frontend turns the result into a question the administrator can answer during the upgrade. It is a poor fit if you need certainty rather than a hint, since the interpreter detection is described as a heuristic that might fail to detect all relevant source files, and a poor fit on a non-systemd, non-legacy-init host, where the fallback depends on hooks for dpkg, rpm or pacman. Before installing it, read INSTALL.md and check what your distribution ships, and note that the last push to the repository was on 2026-09-29 with the most recent tagged release v3.11 from 2025-04-13, so the versions your distribution packages may be behind the repository.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. liske/needrestart on GitHub
4. README
5. Releases