kmon: a terminal UI for Linux kernel modules and kernel activity

The gap kmon fills between modprobe and dmesg

Managing Linux kernel modules normally means switching between several tools. The README names lsmod for listing loaded modules, modprobe or insmod/rmmod for loading and unloading, and dmesg for reading the kernel message buffer. Each has its own output format and its own invocation. kmon's stated goal is to gather these tasks in a single terminal window.

The project describes itself as providing a text-based user interface for managing Linux kernel modules and monitoring kernel activities. Managing, in its own wording, means loading, unloading, blacklisting and showing the information of a module. The audience is therefore someone who is already comfortable at a Linux shell and wants a live view rather than a pipeline of commands. It is not a tool for application developers who never touch module state, and it is not a general system monitor in the sense of CPU and process graphs.

How kmon is built: ratatui, termion and a small dependency set

The Cargo.toml shows the shape of the program. The interface is built on ratatui 0.29.0 with default features off and the termion backend enabled, with termion 4.0.3 as a direct dependency. Supporting crates are narrow in scope: bytesize for formatting sizes, unicode-width for terminal cell widths, colorsys for colour handling, enum-iterator for iterating enum variants, clap for argument parsing, copypasta-ext for clipboard access, and regex-lite for pattern matching.

The build script is where the command line surface is generated. Build dependencies include clap_mangen and clap_complete alongside clap, so man pages and shell completions are produced at build time rather than shipped as static files. That is a detail worth knowing if you package kmon yourself, because it means the build step is not purely a compile.

Release builds are tuned aggressively: opt-level 3, LTO enabled, codegen-units 1, and panic set to abort in both dev and release profiles. The abort setting means a panic terminates the process instead of unwinding. For a TUI that restores the terminal on exit, that choice is worth being aware of, since an abnormal exit path is exactly where terminal state can be left in a bad condition.

Installing kmon and taking a first look at kernel modules

The README links to crates.io and to the Arch Linux extra repository, which is the packaging the project advertises. On Arch you would install the packaged build; elsewhere the crate is the documented route. The repository also carries a Dockerfile, whose runtime stage installs the kmod package and runs ./kmon as its command, so a container build is possible as well.

To install from crates.io with a Rust toolchain present:

cargo install kmon

After that, running kmon with no arguments opens the interface. The README describes the tool as covering module information, loading, unloading and blacklisting, plus a real-time activity monitor, so the first useful thing to do is find a module you recognise and read its details rather than change anything. If you want to reproduce the module lifecycle the project uses as its own example, the example directory contains a minimal loadable module with a Makefile:

make
sudo make install
sudo modprobe lkm_example
sudo modprobe -r lkm_example

The README shows the expected dmesg output from that cycle as a loaded line followed by an unloaded line. That is the kind of event the activity monitor is meant to surface while you work.

Where kmon is the wrong tool

kmon is a text-based user interface. That is the central constraint, and it rules out a whole class of use. If you need to load a module as part of a provisioning script, a container entrypoint, or a systemd unit, an interactive TUI is the wrong shape for the job; modprobe and rmmod are the tools that belong there. kmon is for the session where a human is looking at the screen.

A second boundary is platform. This is Linux-specific by construction, down to the kernel module model and the /lib/modules layout the README describes. There is no macOS or Windows story, and the Dockerfile's runtime image is Debian-based with kmod installed, which tells you the container is expected to run on a Linux host with the relevant kernel interfaces available.

The README does not document rollback behaviour, and it does not describe what happens if a module fails to unload because it is in use. Those are the moments where a wrapper around modprobe is least able to help, because the underlying kernel refusal is the real answer.

kmon compared with plain kmod and dmesg workflows

The honest comparison is not against another TUI. It is against the shell commands kmon wraps. A dmesg | tail pipeline and an lsmod call are composable: you can grep them, pipe them into a log collector, and run them from cron. kmon deliberately gives that up in exchange for a single live view where module state and kernel messages sit next to each other.

If your work is exploratory, that trade is favourable. If your work is repeatable, it is not. The other relevant difference is dependency weight. A shell built from coreutils and kmod has essentially no install cost; kmon brings a Rust binary plus the ratatui and termion stack, which matters on a minimal system where you would rather not add a toolchain or a package just to inspect modules.

There is also the question of what each tool shows. Plain modprobe tells you success or failure and nothing else. kmon's stated purpose includes showing module information and blacklisting, which are actions you would otherwise perform by editing files under /etc/modprobe.d by hand. That is a genuine convenience, and it is also the reason to be careful: a TUI that edits module configuration on your behalf is a place where a misclick has a lasting effect.

Maintenance, licensing and upgrade cost

The repository is not archived. The last push was on 2026-09-21, three days before this writing, so the project is receiving commits. That is separate from release cadence: the most recent release listed is v1.7.1 from 2024-12-15, preceded by v1.7.0 on 2024-12-12 and v1.6.5 on 2024-04-12. Commits and tagged releases are moving at different speeds, which is worth knowing if you pin to tags rather than tracking master.

The crate version in Cargo.toml is 1.7.1, matching the latest release. The CHANGELOG.md at the repository root is the file to read before upgrading, since the README does not carry an upgrade section.

Licensing is GPL-3.0, stated in both Cargo.toml and the LICENSE file. For most users running kmon as a tool this is unremarkable. It becomes relevant if you intend to link the code into your own program or redistribute a modified binary, because GPL-3.0 carries obligations that permissive licences do not. That is a question for your own legal review, not something to settle from a README badge.

Editorial conclusion

Adopt kmon if you already work with modprobe and dmesg on a Linux box and want module state and kernel messages in one terminal window. Skip it if you need scripted, non-interactive module management, since the interface is a TUI. Before installing, confirm your distribution packages kmon or that you have a Rust toolchain for cargo install, and check the CHANGELOG for the release you are getting.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. orhun/kmon on GitHub
3. Project website
4. README
5. Releases