In this lesson, you will learn how to diagnose and forcefully address "Module Busy" errors caused by hidden resource dependencies that prevent standard unloading.
The "Module Busy" Trap
In a modular kernel, every module maintains a reference count. When you execute rmmod or modprobe -r, the kernel checks if this count is zero. If the count is greater than zero, the kernel refuses to unload the module to prevent a system crash. Usually, this means another module is using your target, or a process has an open file descriptor on a device node managed by that module.
However, sometimes the kernel reports a module as "busy" even when no obvious dependencies exist. This happens due to zombie references or lingering resource bindings—such as a network socket that failed to close gracefully, or an interrupt handler that wasn't properly unregistered during the module’s cleanup routine.
Forcing the Unload
When standard attempts fail, you can utilize the f (force) flag. While risky, it is the primary tool for administrators dealing with stale modules:
# Attempt a standard unload
sudo modprobe -r <module_name>
# If that fails due to "Module is in use", force it:
sudo rmmod -f <module_name>
Caution: The -f flag tells the kernel to bypass the refcount check and immediately unmap the module’s code from memory. If any process or kernel thread attempts to access the code that was just unmapped, you will trigger a kernel panic.
Identifying the Hidden Hook
Before forcing, check what is holding the reference. You can often find clues by inspecting /proc/modules:
# Look at the third column in the output
cat /proc/modules | grep <module_name>
If the third column shows a non-zero integer, that number represents the current reference count. If you see another module listed at the end of that line, that module is the dependency preventing the unload. You must unload the dependent module first before the primary module can be released. If the count is high but no dependencies are listed, look for active user-space processes using lsof /dev/<module_device> and terminate them manually before attempting to force the module removal.
Key Takeaway: When a module refuses to unload, identify hidden dependencies via /proc/modules or open file handles; use the -f flag only as a last resort, knowing it sacrifices stability to clear the memory block.