Read Loaded Kernel Modules Clearly with lsmod

You will use lsmod to see which Linux kernel modules are loaded, identify modules that depend on one another, and check whether an apparent empty result is a real system state or a missing /proc interface. The commands are read-only: they do not load, unload or reconfigure a module.

Allow about ten minutes. You need a shell on the Linux host you want to inspect. No elevated privilege is normally required. This guide describes kmod 31+20240202-2ubuntu7.2, the package installed on the reference system; output order and the particular modules will differ on other kernels.

1. Run the basic listing

Run lsmod without arguments. Its installed manual documents no command-line operands: the command formats the contents of /proc/modules.

$ lsmod
Module                  Size  Used by
ip_set_hash_ip         49152  0
macsec                 77824  0
algif_hash             12288  0
cpuid                  12288  0
8021q                  45056  0

Your list is a snapshot of the running kernel, not a list of every module installed on disk. A module can be available for loading and absent from this output. Conversely, a module shown here is currently present in the kernel, even if no package manager recently changed anything.

$ lsmod > /tmp/lsmod-before.txt
$ test -s /tmp/lsmod-before.txt && echo "listing captured"
listing captured

2. Read the three useful columns

Each row has a module name, its size in bytes, and a use count followed by names of modules that use it. For example, a row such as garp 20480 1 8021q says that garp is listed with size 20480 and use count 1, with 8021q shown in the users column.

The use count is not a measure of traffic, performance or importance. It is kernel reference information. A zero does not mean that a module is broken; it means no current user is recorded in that column. A non-zero count is one reason an unload may be refused. Do not infer that unloading is safe from a zero alone.

Module names may contain underscores where a configuration or hardware description uses a hyphen. Treat the exact name printed by lsmod as authoritative when you investigate it.

3. Find one module without losing the header

For a quick human check, filter the listing after it has been produced:

$ lsmod | grep -E '^(Module|8021q[[:space:]])'
Module                  Size  Used by
8021q                  45056  0

Replace 8021q with a module name from your own listing. The beginning-of-line match matters: a dependent module name later in the users column is not the same as a row for that module. If the command returns only the header, that module is not listed as loaded.

Distraction trap: a module name is not a complete search term when it is also a substring of another name. Use the anchored expression above, or inspect the full row manually before drawing a conclusion.

4. Cross-check the kernel's source data

The lsmod manual describes the command as a formatter for /proc/modules. Compare the first few raw rows with the formatted listing:

$ sed -n '1,6p' /proc/modules
ip_set_hash_ip 49152 0 - Live 0x0000000000000000
macsec 77824 0 - Live 0x0000000000000000
algif_hash 12288 0 - Live 0x0000000000000000
cpuid 12288 0 - Live 0x0000000000000000
8021q 45056 0 - Live 0x0000000000000000

The raw format is kernel-facing and is not as convenient to read. Its first fields correspond to the module name, size and use count, while later fields include state information. Do not script against the displayed spacing in lsmod; if you need the source interface, parse /proc/modules with care and validate assumptions against the kernel version.

5. Check whether a module is loaded, not merely installed

Use an exact first-column test when a script needs a yes-or-no answer. This example keeps the module name in one obvious variable:

module_name='8021q'
if lsmod | awk -v wanted="$module_name" 'NR > 1 && $1 == wanted { found = 1 } END { exit !found }'; then
    echo "$module_name is loaded"
else
    echo "$module_name is not listed as loaded"
fi

The test only answers whether the running kernel lists that exact name. It does not prove that the module file exists, that its hardware is present, or that a future load will succeed. Do not add sudo just because the result is negative: lsmod reads status and normally works as the invoking user.

6. Diagnose an empty or failing result

If lsmod prints no rows or reports that /proc/modules cannot be opened, check the interface directly:

$ test -r /proc/modules && echo "/proc/modules is readable" || echo "/proc/modules is unavailable"
/proc/modules is readable

In a container, restricted namespace or unusual recovery environment, /proc may be absent, partially mounted or deliberately hidden. That is an environment boundary, not evidence that the host has no modules. Inspect the host using its own namespace and permissions before changing mounts or container configuration.

If a row appears but its numbers look surprising, remember that module state can change while you are reading it. Repeat lsmod and compare the complete rows rather than joining a size from one snapshot to a use count from another. The command is an observation tool, not a lock on kernel state.

7. Keep state-changing tools separate

lsmod does not load or remove modules. Tools such as modprobe, insmod and rmmod have different purposes and may require elevated privileges. Do not copy a state-changing command into a diagnosis simply because a module is absent from the listing.