swapoff is the quieter sibling of swapon — less frequently used, but genuinely important to understand well, because getting it wrong (or misunderstanding what it does under the hood) can cause a system to grind to a halt if you disable swap on a box that’s actually depending on it. This guide covers the command itself, what actually happens internally when you run it, and when disabling swap is (and isn’t) a reasonable thing to do.
What swapoff Does
swapoff deactivates a previously enabled swap device or file, removing it from the kernel’s pool of available swap space.
sudo swapoff --help
Usage:
swapoff [options] [<spec>]
Disable devices and files for paging and swapping.
Options:
-a, --all disable all swaps from /proc/swaps
-v, --verbose verbose mode
-h, --help display this help
-V, --version display version
The <spec> parameter:
-L <label> LABEL of device to be used
-U <uuid> UUID of device to be used
LABEL=<label> LABEL of device to be used
UUID=<uuid> UUID of device to be used
<device> name of device to be used
<file> name of file to be used
Basic Usage
sudo swapoff /swapfile
sudo swapoff /dev/sdb2
sudo swapoff -a
-a disables every currently active swap area, as listed in /proc/swaps at the time of execution.
The Critical Thing swapoff Does That Most People Don’t Realize
Here’s the part that genuinely matters, and trips people up if they don’t know it: swapoff doesn’t just detach the swap area — it first migrates every page currently stored in that swap space back into physical RAM.
This makes sense once you think it through: if some process’s memory pages are sitting on that swap device right now, and you’re about to make it unavailable, the kernel has to move that data somewhere before it can safely let go — and the only place left is back into physical RAM.
This has a very real, practical consequence: if you run swapoff on a system where swap is actively in use, and there isn’t enough free physical RAM to absorb everything currently swapped out, the command will fail, or in more severe overcommit situations, the system can experience serious memory pressure while it’s happening — potentially triggering the OOM killer or causing significant slowdown while pages get paged back in.
Before disabling swap, always check how much is actually in use:
swapon --show
NAME TYPE SIZE USED PRIO
/swapfile file 2G 512M -2
or:
free -h
total used free shared buff/cache available
Mem: 3.9Gi 249Mi 3.7Gi 4.3Mi 153Mi 3.7Gi
Swap: 0B 0B 0B
(In this particular example, swap total is 0B, meaning no swap is configured at all on this system — swapoff would have nothing to do here. On a system with active swap usage, confirm the USED figure is small enough that your available RAM can safely absorb it before proceeding.)
Full Workflow: Safely Disabling Swap
# 1. Check current swap usage first
swapon --show
free -h
# 2. Confirm you have enough free RAM to absorb what's currently swapped
# (compare 'used' swap against 'available' memory)
# 3. Disable it
sudo swapoff /swapfile
# 4. Confirm it's gone
swapon --show
cat /proc/swaps
If you also want to remove a swap file entirely (not just deactivate it):
sudo swapoff /swapfile
sudo rm /swapfile
And remember to remove the corresponding entry from /etc/fstab, or the next boot will try to activate a swap file that no longer exists, generating a boot-time warning (or in strict configurations, a failed mount unit).
Why You’d Want to Disable Swap At All
- Resizing or relocating swap — you need to shrink, grow, or move a swap partition/file, which requires deactivating it first.
- Troubleshooting suspected swap-related performance issues — temporarily disabling swap to confirm whether a performance problem is actually swap-related, though this should be done cautiously and briefly, since removing swap entirely on a memory-constrained system can make things dramatically worse, not better, if you’re wrong about the cause.
- Certain specialized workloads — some latency-sensitive real-time or in-memory database workloads deliberately run with swap disabled entirely, on systems provisioned with enough RAM that swap would never help and could only introduce unpredictable latency if triggered.
- Container and Kubernetes environments — historically,
kubeletrequired swap to be disabled entirely on nodes (a hard requirement in many versions), since Kubernetes’ memory accounting and eviction model wasn’t designed to account for swapped memory. This has been evolving with alpha/beta swap support in more recent Kubernetes versions, but disabling swap remains common practice on many container-orchestrated hosts.
Practical Sysadmin Examples
Resizing a swap file (shrink or grow):
sudo swapoff /swapfile
sudo rm /swapfile
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
Disabling all swap for a Kubernetes node setup:
sudo swapoff -a
sudo sed -i '/ swap / s/^/#/' /etc/fstab
The sed command here comments out any swap line in /etc/fstab, preventing it from being re-enabled automatically on the next boot — a common step in Kubernetes node preparation playbooks (Ansible, kubeadm pre-flight checks explicitly look for this).
Safely testing whether swap is masking a real memory problem:
free -h
sudo swapoff -a
# monitor system behavior closely here
free -h
sudo swapon -a # re-enable promptly if things degrade
This kind of test should only be done on a non-production system, or during a controlled maintenance window, given the risk of triggering serious memory pressure.
Monitoring a swapoff Operation in Progress
On a system with a meaningful amount of data in swap, swapoff isn’t instantaneous, and it’s worth actually watching it happen rather than just waiting blindly. Running these in a second terminal session while swapoff executes gives real visibility into what’s going on:
watch -n1 'free -h; echo; grep -A1 Dirty /proc/meminfo'
vmstat 1
In the vmstat output, watch the si (swap-in) column specifically — this is the rate at which pages are being read back from swap into RAM as part of the swapoff process. A steadily decreasing swpd value in vmstat -s output, alongside a shrinking USED figure in swapon --show (if you check it in a loop before the swap area fully disappears), confirms the operation is progressing rather than stuck.
watch -n1 swapon --show
If si stays elevated for a long period without the used swap figure decreasing, and system responsiveness is visibly degrading, that’s the signal to consider aborting the plan (there’s no direct “abort” for swapoff itself, but you can reduce memory pressure elsewhere, or in an extreme case, accept the risk and let it complete since there’s no safe way to reverse a swapoff that’s already in progress).
The Kubernetes and Container Context in More Depth
It’s worth expanding on why swapoff -a shows up so often in infrastructure automation, since it’s one of the more common real-world contexts this command appears in outside of manual sysadmin work. Kubernetes’ kubelet component historically refused to start at all if it detected active swap on the node, specifically because Kubernetes’ resource accounting and Quality-of-Service (QoS) eviction model assumes a process’s memory usage figure reflects real physical memory pressure — if some of that “used” memory is actually sitting in swap, the scheduler’s decisions about which pods to evict under memory pressure become unreliable.
This is why provisioning tools like kubeadm, cloud-init scripts for managed Kubernetes node pools, and configuration management playbooks (Ansible roles for Kubernetes nodes are a common example) almost universally include a step equivalent to:
sudo swapoff -a
sudo sed -i '/ swap / s/^/#/' /etc/fstab
More recent Kubernetes versions have introduced alpha/beta support for running with swap enabled under specific configurations, but disabling it entirely remains the default, safest, and most widely deployed approach — worth knowing if you’re setting up a Kubernetes node yourself and wondering why documentation insists on this step rather than treating it as optional.
Troubleshooting
swapoff: /swapfile: swapoff failed: Cannot allocate memory→ the system doesn’t have enough free physical RAM to absorb everything currently in swap. Free up memory first (stop non-essential services, clear caches) or add temporary additional swap elsewhere before retrying.- System becomes sluggish or unresponsive during
swapoff→ this is the page-in process happening under memory pressure; it should resolve once complete, but on a genuinely memory-constrained system, consider aborting the plan and re-enabling swap instead of waiting it out. - Swap re-appears after reboot despite running
swapoff→swapoffonly affects the current running session; the persistent configuration in/etc/fstabneeds to be updated (commented out or removed) separately, or a systemd swap unit needs to be disabled. swapoff -aseems to hang → checkvmstat 1in another session; ifsi(swap-in) is climbing steadily, it’s actively working through migrating pages back to RAM, which can take real time on systems with a lot swapped out and slow storage.
Performance and Capacity Planning Considerations
Disabling swap entirely on a system that’s genuinely memory-constrained removes the kernel’s safety valve for handling temporary memory spikes gracefully — instead of quietly swapping a rarely-used page to disk, the kernel now has no choice but to invoke the OOM killer the moment physical memory runs out, which means a process gets forcibly terminated rather than the system experiencing brief slowdown. Before permanently disabling swap on a production system, be confident that physical RAM genuinely exceeds peak memory demand with real margin, not just typical/average demand.
Security Implications
swapoff itself is a low-risk administrative operation, but the broader context matters: if a swap area contained sensitive data (credentials, key material that briefly got paged out) and you’re decommissioning that swap file or partition permanently, simply deleting the file isn’t sufficient to guarantee the underlying disk blocks are unrecoverable — on traditional spinning disks and even some SSDs, remnants can persist until overwritten. For genuinely sensitive environments, consider secure-erase tooling (shred, or full-disk encryption from the start, which sidesteps this problem entirely since the underlying blocks are encrypted regardless of what deleted them).
A Note on Automated Swap Management
Some systems run lightweight daemons or cron-based scripts that dynamically manage swap — activating extra swap space automatically when memory pressure crosses a threshold, and deactivating it again once pressure subsides, rather than leaving a large, fixed swap area permanently active. If you’re troubleshooting a system where swap seems to appear and disappear on its own without anyone manually running swapon/swapoff, it’s worth checking cron, systemd timers, and any custom monitoring agents before assuming something unusual is happening — this kind of dynamic swap management is a legitimate, if somewhat uncommon, pattern on memory-constrained systems that want the benefits of swap availability without the constant overhead of a large permanently-active swap file.
swapoff vs Related Commands
| Command | Purpose |
|---|---|
swapoff | Deactivate a swap device or file, migrating its contents back to RAM first |
swapon | Activate a swap device or file |
mkswap | Format a device/file as swap (must be done before it can be activated) |
free -h | Quick check of current swap usage before deciding whether it’s safe to disable |
vmstat 1 | Watch live paging activity (si/so) during a swapoff operation |
Compatibility Across Distributions
swapoff, like swapon, is part of util-linux and behaves identically across all mainstream distributions — Debian, Ubuntu, RHEL, Fedora, Arch, openSUSE. The broader ecosystem context differs more than the command itself: distributions and orchestration tools (Kubernetes node bootstrapping scripts, for instance) increasingly script swapoff -a combined with fstab edits as a standard provisioning step, so you’ll encounter this command frequently in infrastructure-as-code and configuration management playbooks (Ansible, Terraform provisioners, cloud-init scripts) even if you rarely type it manually.
Summary
The one fact worth internalizing above everything else in this guide: swapoff has to move every currently-swapped page back into RAM before it can complete, which means it can genuinely fail — or cause real memory pressure — if you don’t check usage first. Always check swapon --show or free -h before disabling swap on any system where memory headroom is uncertain, and remember that deactivating swap for the current session and permanently removing it from boot configuration (/etc/fstab) are two separate steps.
References
man 8 swapoffman 8 swaponman 8 mkswap- Linux kernel documentation on memory management:
Documentation/admin-guide/mm/