Why updates sometimes need a restart

Updated: Oct 28, 2026

Some updates replace files that a running process already loaded into memory. The old code can continue running until the process restarts, so the operating system schedules a restart to ensure every component uses the new version. That is the short version. The longer version explains why a restart is sometimes unavoidable, why other updates apply silently, and how to plan restarts so they never become an emergency.

If you have ever installed a security patch and then postponed the restart for a week, you have effectively been running the old, vulnerable code for that week. The files on disk were new, but the copy in memory was not. Understanding this gap is the key to understanding restart prompts.

Why running files cannot simply be replaced

When a program starts, the operating system reads its executable file and the libraries it depends on into memory. From that point on, the process works with the copy in RAM. If an updater later overwrites the file on disk, the running process is not affected: it continues executing the instructions it already loaded. The new version only becomes active when a fresh process starts and reads the new file.

For an ordinary application such as a text editor, this is easy to handle. The updater can close the app, replace the files and reopen it, or simply ask you to relaunch it. For components that are used by everything else, the situation is different:

• The kernel is loaded once at boot and cannot be swapped while the system is running (a few systems support live patching for specific fixes, but it is the exception, not the rule).
• Drivers talk directly to hardware and are often loaded by the kernel itself, so a new driver usually needs a clean initialisation.
• Shared libraries such as the C runtime or an SSL library are loaded by hundreds of processes. Replacing the file on disk does nothing for processes already running; each one must restart to pick up the fix.
• Core services like the display manager, network stack or the update service itself cannot always be stopped without ending the user session.

On Windows, files that are in use are locked, so the installer stages the new files and asks the system to swap them during the next boot, before the locked processes start again. On Linux and macOS, an open file can be replaced on disk while the old inode stays alive for the running process. That is why Linux servers can install most updates without a reboot, yet still need one for kernel and libc changes. Tools such as needrestart or checkrestart exist precisely to list processes that are still using deleted library versions.

Why postponing a restart matters

A security update that is installed but not activated gives a false sense of safety. The package manager reports the new version, monitoring dashboards turn green, yet the vulnerable code is still executing. Attackers do not check which version is written on disk; they exploit whatever is running.

There is a second, less obvious risk. When part of a system uses new files and part still uses old ones, the two halves can disagree. A desktop environment may load an updated plug-in that expects a newer version of a library than the one already in memory, leading to crashes that look random. Restarting promptly removes that mixed state.

Restarts on servers and shared hosting

On a server, a restart interrupts every request in flight, so the goal is to make it predictable rather than to avoid it entirely. The usual pattern is:

1. Take a fresh backup or snapshot so a bad update can be rolled back.
2. Drain traffic: stop accepting new connections and let current requests finish. Web servers and application runtimes usually offer a graceful shutdown mode for this.
3. Restart during a maintenance window, then run health checks against the real endpoints, not just “is the process alive”.
4. Keep the previous kernel or package version available for one boot cycle so recovery is a menu choice, not a rebuild.

In a cluster, nodes are restarted one at a time so the service never disappears entirely. On shared hosting you often cannot restart the machine yourself; instead the provider does it, and your job is to make sure your application starts cleanly on its own, with no manual steps required.

When to restart and when it can wait

• Treat “restart required” as the final step of the update, not as an optional extra. Until you restart, the fix is not protecting you.
• Schedule restarts at a time you choose. Most systems let you pick an active-hours window so the restart does not interrupt work.
• Save your work and close applications yourself before restarting; letting the system force-close them is where documents get lost.
• On servers, combine restarts with backups, graceful shutdowns and health checks, and restart cluster nodes one by one.
• If a restart prompt appears in a browser pop-up or an email, be suspicious. Genuine restart requests come from the operating system or the application itself, not from a web page.

Frequently asked questions

Why does my phone restart for updates when my laptop often does not?

Mobile operating systems update the system image as a whole and verify it at boot, which requires a restart. Laptops install many smaller packages, and only a few of those touch components that need a reboot.

Is it safe to keep postponing?

For feature updates, a short delay is harmless. For security updates, every day of delay is a day the known vulnerability remains exploitable on your device. A good compromise is to postpone by hours, not weeks.

Can I avoid restarts on a server completely?

Not entirely. Live kernel patching reduces how often you must reboot, but library updates still require restarting the services that use them, and eventually a full reboot keeps the system in a known, consistent state.

A restart is often the final step that makes an update active, not evidence that the update failed.

In short: Updates change files on disk, but running programs keep using the code already in memory. A restart is how the new version actually takes over, so plan it, do not fear it and do not postpone security fixes for long.