Safely Remove a Kernel Module with rmmod

rmmod unloads a live kernel module, and that is precisely why it deserves more caution than a name this short suggests. This guide matches kmod 31, and takes about ten minutes for a simple module, longer for anything tied to network, storage or security.

You need a shell, the kmod package, and elevated privileges only for the actual removal step. The local rmmod(8) manual itself recommends modprobe -r for most people, since it can also remove unused dependent modules.

1. Check the installed command

Start with read-only checks that need no sudo:

$ command -v rmmod
/usr/sbin/rmmod
$ rmmod --version
kmod version 31
+ZSTD +XZ -ZLIB +LIBCRYPTO -EXPERIMENTAL

Checkpoint: confirm the command is the expected kmod utility and note its version before scripting anything around it.

2. Find the module and who is using it

List loaded modules and their use counts:

$ lsmod
Module                  Size  Used by
...
MODULE_NAME             16384  0

Swap MODULE_NAME for a real name from your output. The Used by column is a useful warning, not a complete safety proof: a non-zero count means other kernel code is using the module and removal will normally fail, but even a zero count does not tell you whether a service will need it again the moment you unload it.

$ modinfo MODULE_NAME
$ systemctl --type=service --state=running

modinfo shows metadata for the module; the service list helps you spot an obvious owner but does not map every module to a service. For a network, storage, filesystem or hardware driver, stop and understand the dependency first. Pulling a live driver can interrupt users, disconnect storage, or leave the system unable to recover without a reboot.

3. Pick the right removal tool

For a module with no dependents, the direct form is:

$ sudo rmmod MODULE_NAME

Most administration work should use the higher-level form instead:

$ sudo modprobe -r MODULE_NAME

The local rmmod(8) manual specifically recommends modprobe -r because it also cleans up unused dependent modules. That is more thorough, but it can also change more kernel state at once, so review the command and its output before accepting it on a production host.

Warning: do not add -f to push past a failed removal. The installed help itself warns that force removal may crash the machine. It only has an effect when the kernel was built with CONFIG_MODULE_FORCE_UNLOAD, and it can remove modules that are still in use, never designed to be removed, or explicitly marked unsafe.

4. Remove one module deliberately

This is the state-changing step, and it normally needs root privileges. Keep a console or out-of-band recovery path available, and do not experiment with a storage, network or security module on a remote host unless you have already tested the recovery plan.

$ sudo rmmod MODULE_NAME
$ printf 'exit status: %s\n' "$?"
exit status: 0

Zero just means rmmod completed the removal request; it is not a health check on whatever depended on the module. A failure sends its ordinary diagnostic to standard error, usually because the module name is misspelled, the module is not loaded, it is still in use, unloading support is missing, or privilege is insufficient. For more detail, repeat the same operation verbosely:

$ sudo rmmod --verbose MODULE_NAME

Only reach for --syslog if your host's logging setup makes that genuinely useful; it just sends errors to syslog instead of standard error and does not make the operation any safer.

5. Verify the result

Check that the module has actually disappeared from the loaded list:

$ lsmod | awk '$1 == "MODULE_NAME" { found=1 } END { exit found ? 0 : 1 }'
$ printf 'still loaded: %s\n' "$?"
still loaded: 1

Here status 1 is the result you want: no matching module found. For a quicker human-readable check:

$ lsmod | grep -E '^MODULE_NAME[[:space:]]' || echo 'MODULE_NAME is not loaded'
MODULE_NAME is not loaded

Then check the service or device that motivated the change in the first place. A module can be gone while a separate user-space failure remains, so test the actual function rather than trusting rmmod's exit status alone.

6. Recover if the removal was wrong

There is no universal undo. If the module is still available in the installed module tree with resolvable dependencies, try loading it back:

$ sudo modprobe MODULE_NAME
$ lsmod | grep -E '^MODULE_NAME[[:space:]]' || echo 'MODULE_NAME is not loaded'

Then restart or recheck the affected service as needed. If modprobe reports the module unavailable, check modinfo MODULE_NAME and the system journal. A reboot can restore a built-in or auto-loaded configuration, but do not treat rebooting as a substitute for understanding why the module was removed in the first place.

Recovery: if removal failed because the module was busy, stop the owning service through its normal management interface, confirm the device is no longer in use, then reassess. Do not force the unload just to get a zero exit status.

Done means