Read /proc/modules to Check Loaded Kernel Modules

You will finish with a repeatable, read-only check of the kernel modules loaded on a Linux system, plus a way to turn the result into a small shell report. Allow about 10 minutes. You need a shell account that can read procfs; the examples do not need root.

What this file tells you

/proc/modules is a kernel-generated text list of modules that are currently loaded. The local proc_modules(5) manual page is deliberately brief: it identifies the file and points to lsmod(8) for a friendlier view. This is status information, not a configuration file to edit.

That distinction prevents the most damaging mistake in this area. Do not open /proc/modules in an editor and do not redirect output into it. Reading it is harmless; loading or removing a module is a separate operation with possible effects on networking, storage, filesystems and hardware.

Checkpoint 1: confirm the host and read the file

1. Record the running kernel and print the first entries from procfs.

uname -r
sed -n '1,12p' /proc/modules

On the machine used for this guide, the kernel is 6.8.0-139-generic. Your list will differ. A line may look like this:

sctp 495616 105 sctp_diag, Live 0x0000000000000000

The first whitespace-separated value is the module name. The next two values are numeric fields supplied by the kernel. The following text describes module relationships and state; it is not safe to infer that a module can be removed merely because one number is zero. The exact layout is kernel-facing data, and it can vary with kernel versions and module state.

Checkpoint 2: use lsmod as the readable comparison

1. Ask lsmod to format the same kernel data.

lsmod

The installed lsmod(8) page describes this program as a formatter for /proc/modules. Its header makes the columns easier to scan:

Module                  Size  Used by
xt_comment             12288  2
ib_core               507904  0
sctp                  495616  105 sctp_diag

This is a presentation aid, not a second source of state. If you are writing a diagnostic script, read /proc/modules directly when you need the kernel's text record, and use lsmod when a person needs a quick terminal report.

On this host, man-pages is version 6.7 and the proc_modules(5) page is dated 2023-08-15. The running kernel is 6.8.0-139-generic. Treat those versions as part of the observation: module lists and formatting are host-specific, not a fixed inventory that can be copied between machines.

Make a small, safe report

1. Print just the module names, preserving the file and leaving the system unchanged.

awk '{print $1}' /proc/modules | sed -n '1,20p'

To test for one exact module name, use a field comparison rather than a substring search. Replace MODULE_NAME with the name you are checking:

module='MODULE_NAME'
awk -v wanted="$module" '$1 == wanted { found=1; print; exit } END { if (!found) exit 1 }' /proc/modules
status=$?
if [ "$status" -eq 0 ]; then
    echo "loaded: $module"
else
    echo "not listed: $module"
fi

The command returns status 0 only when the exact first field is found. A non-zero result means that this snapshot did not list the name; it does not prove that a package is absent or that a device cannot use a built-in kernel feature. A driver compiled into the kernel is not a loadable module and will not appear here.

Compare two snapshots without making changes

1. Save two read-only snapshots and compare their module names.

snapshot_dir="${TMPDIR:-/tmp}"
before="$snapshot_dir/proc-modules-before.$$.txt"
after="$snapshot_dir/proc-modules-after.$$.txt"
awk '{print $1}' /proc/modules | sort > "$before"
printf '%s\n' "Use the system normally, then press Enter to take the second snapshot."
read -r
awk '{print $1}' /proc/modules | sort > "$after"
diff -u "$before" "$after"
rm -f "$before" "$after"

The temporary files contain module names only and are removed at the end. If you need to investigate a transient change, copy them to a controlled diagnostic location before the final rm. That removal is the only state-changing command in this example, and it affects only the two files named by the script.

What not to conclude from the list

• A listed module is loaded now, not necessarily responsible for the symptom you are investigating.
• A missing name does not mean the feature is unavailable; it may be built into the kernel, unavailable in this namespace, or named differently.
• The list is a snapshot. Modules can be loaded or unloaded while you inspect it, so take a fresh reading before acting.
• Do not use a module count as a security control. Check the specific kernel configuration, device state and service behaviour that your control actually depends on.

If you must change module state, stop and identify the exact administrative command and its recovery plan first. Loading a module may alter device behaviour. Removing one can interrupt a service or make storage and networking unavailable. Neither action is required to complete this guide, and no undo command can reliably restore every dependent service automatically.