Arch Linux security updates: keeping a server patched

Updated November 2026

Arch Linux has one way to get security fixes: a full system upgrade with sudo pacman -Syu, run often. There are no releases, no security-only channel and no long-term support, so an Arch server is only as safe as its last full upgrade.

Releases and support

Arch is a rolling release. There are no version numbers to track and no end-of-life dates (as of November 2026). Instead, the project only supports systems that are fully up to date. When a library changes, Arch rebuilds every package that depends on it, and the new set of packages only works together. That is why the rest of this page keeps coming back to one rule: always upgrade everything at once.

Arch ships two main kernels in its official repositories: linux (the default kernel) and linux-lts (an upstream long-term-support kernel, useful as a fallback or for out-of-tree modules). Both get security fixes through normal upgrades.

Check what you are running

uname -r
pacman -Q linux linux-lts
checkupdates

uname -r shows the running kernel; pacman -Q shows the installed packages (an error for linux-lts just means it is not installed). checkupdates, from the pacman-contrib package, lists pending updates safely: it uses a separate temporary database, so it never leaves your system half-synced.

Before you upgrade

Arch posts a news item whenever an update needs manual steps. Check the Arch Linux home page, its news RSS feed, or subscribe to the arch-announce mailing list. The Arch wiki also advises against upgrading a production machine just before it is needed for something important, and suggests testing updates on a duplicate system first if you cannot afford downtime.

Apply security updates now

sudo pacman -Syu

This syncs the package databases (-Sy) and upgrades every installed package (-u). Read pacman’s messages as it runs and act on any that ask you to do something.

Never do a partial upgrade. Do not run pacman -Sy on its own, pacman -Sy package, or pacman -Sy followed later by pacman -S package. Each of these can install a new library next to old programs that need the old one, and break them. To install a package, use sudo pacman -Syu package. If pacman -Syu fails part way, fix the error and finish the upgrade before you do anything else with pacman.

Server that has not been updated for a while

Package signatures can fail if the archlinux-keyring package is too old. The Arch wiki gives this sequence, which is not a partial upgrade because it updates the keyring and then immediately upgrades everything:

sudo pacman -Sy --needed archlinux-keyring && sudo pacman -Su

Also make sure the system clock is right (use NTP); a wrong date makes valid keys look expired.

Configuration files

When an update ships a new default config file that you have edited, pacman saves it as .pacnew next to yours. Merge these promptly; a security fix sometimes includes a config change. pacdiff (from pacman-contrib) finds them and helps you view, merge or remove them:

sudo pacdiff

Is a package vulnerable?

Arch has no security-only updates, but arch-audit (official repositories) compares your installed packages with the Arch security tracker:

sudo pacman -Syu arch-audit
arch-audit
arch-audit -u
arch-audit -c

Plain arch-audit lists installed packages with known issues. -u shows only those where a fixed version is already in the repositories, which means a pacman -Syu will fix them. -c adds the CVE numbers.

Do not rely on the tracker alone. The Arch wiki currently marks the security team page as out of date because the tracker “is currently not updated”. The tracker published almost no advisories between June 2025 and October 2026. An empty arch-audit result does not prove a system is safe; upgrading often does more for you than any report.

Automatic updates

Arch does not ship an unattended-upgrade tool, and its documentation expects a person to read the news, answer pacman’s prompts and merge .pacnew files. Running pacman -Syu --noconfirm from cron can therefore leave a server broken with nobody watching. Safer options:

See automatic updates for the general trade-offs.

Restart services and reboot

An upgrade does not change programs that are already running; they keep the old code until restarted. The archlinux-contrib package includes checkservices, which runs pacdiff, finds services still using old libraries and offers to restart them (restarting briefly interrupts each service). Afterwards check that nothing failed:

systemctl --failed

Kernel updates

A new kernel is only used after a reboot. On Arch this matters more than elsewhere: when pacman installs a new kernel it removes the modules of the running kernel from /usr/lib/modules/. Until you reboot, the system may fail to load modules it has not loaded yet, such as a USB device driver or a file system it has not mounted. The Arch wiki’s advice is to reboot after every kernel update:

sudo reboot

(This restarts the server.) The kernel-modules-hook package keeps the old modules around until you reboot, which avoids the module problem but not the need to reboot. Arch offers no ready-made kernel live patches; its wiki only describes building kpatch modules yourself against a specially built kernel, which is not a practical way to patch production servers. Plan regular reboots instead. See kernel updates.

Where Arch publishes advisories

A long-neglected Arch server

Sources