Why An Update Needs A Restart To Finish

An update downloads in the background and then insists on a restart. The requirement is not caution, it comes from what an operating system will and will not allow.

Running code is locked in place

When a program runs, its files are mapped into memory and the system may load further portions of them at any moment.

Replacing such a file mid-execution risks a program that has half of one version and half of another in memory, which fails unpredictably.

Some systems prevent this outright by refusing to modify a file in use. Others permit it, and the running program continues using the old contents until it exits.

Shared components multiply the problem

An update rarely touches one file. Libraries used by many programs at once must all be replaced together, because versions are only tested as a set.

If half the set is replaced while programs are running, some will be linking new code against old and will misbehave in ways that are hard to diagnose.

Restarting guarantees that everything starts from the same version. It is a crude solution and a reliable one.

Staging separates download from installation

Updates are therefore prepared in advance. New files are written alongside the old ones, verified, and marked ready without anything being replaced.

At restart, a small component running before the main system starts performs the swap, when nothing else holds any file open.

This is why a restart that applies updates takes far longer than an ordinary one, and why the download can complete hours before anything changes.

Rollback depends on keeping the old version

Because the previous files are retained until the new system boots successfully, a failed update can be reversed by pointing back at what was there.

Some systems formalise this with two complete copies, updating the inactive one and switching between them at boot.

That approach makes updates nearly instantaneous and failure recoverable, at the cost of permanently reserving twice the space for the system.

Live patching exists in narrow cases

Servers that cannot restart use techniques that redirect individual functions to new implementations while the system runs.

It works only for changes that do not alter data structures or the meaning of existing state, which excludes most substantial updates.

The restriction is why the technique remains specialised. For a general update touching many components, stopping and starting cleanly is still the only approach that can be trusted.