Detect Hardware Monitoring Chips with sensors-detect

sensors-detect probes your hardware directly, and the manpage warns that a bad probe can lock an SMBus or, rarely, damage hardware. You finish with a documented scan and a clear call on whether to load the modules it finds.

This guide targets sensors-detect from lm-sensors 3.6.0, packaged here as lm-sensors 1:3.6.0-9build1. Allow 15 to 30 minutes, including a reboot or maintenance window if you decide to load a new module.

• Needs: a Linux shell, the lm-sensors package, and physical or console access to the machine.
• Do this first: run the scan on a test host or a workstation.
• Risk: do not run it on a production server that you cannot afford to interrupt or repair.

1. Confirm the installed command

Check the binary and package as an ordinary user. These commands only inspect the installation:

$ command -v sensors-detect
/usr/sbin/sensors-detect
$ dpkg-query -W -f='${Package} ${Version}\n' lm-sensors
lm-sensors 1:3.6.0-9build1

The installed manual describes this release as lm-sensors 3 and gives the command one documented option, --auto. The normal invocation is interactive. That is useful because you can see which probe is about to run and decline an extra detection stage when the default logic skips it.

2. Prepare a safe maintenance window

Save work and arrange an out-of-band console if the machine is remote. Close applications that depend on the network if you are testing a workstation. The scan normally completes quickly, but the warning is about the possibility of a bus lockup, not merely a slow command.

Do not force the later ISA or SMBus/I2C stages just to obtain a longer list. sensors-detect first checks sensors embedded in CPUs, south bridges and memory controllers, then Super I/O chips. If a Super I/O chip already provides complete hardware monitoring, it normally skips the riskier final stages. The manpage specifically recommends leaving a skipped stage alone unless you understand why a second monitoring chip is expected.

3. Run the interactive scan

Start the command from a terminal. It needs hardware access for most detections, so the command will normally need elevated privileges:

$ sudo sensors-detect

Read each prompt before answering. The default answer is generally the conservative choice when the program offers to continue to another probe family. Press Enter to accept a displayed default only after checking what that default is. If you are unsure, answer no and record that the stage was skipped.

Expect the program to examine these areas in order:

1. CPU, south bridge and memory-controller sensors.
2. Super I/O chips.
3. Hardware monitoring chips at ISA I/O ports, when the scan proceeds that far.
4. Hardware monitoring chips on SMBus or another I2C bus, when the scan proceeds that far.

The exact output is machine-specific. A useful result identifies one or more chips and suggests kernel modules. A scan that finds nothing is still a valid result: the hardware may be unsupported, already hidden by firmware, or outside the detection paths supported by this version.

4. Record the module recommendations

Near the end, the program usually prints a suggested next step for loading detected modules. Treat that text as a recommendation for this host, not a universal configuration recipe. Copy the detected chip names and module names into your change record before closing the terminal.

Do not blindly paste a generated command into a startup file. A module can expose readings that are wrong, incomplete or unsuitable for a particular board. Research the exact module and board combination first, then test it during the same maintenance window.

When you need a repeatable record, capture the terminal transcript without pretending that output from another machine is expected:

$ sudo sensors-detect 2> sensors-detect.err | tee sensors-detect.out
$ test ! -s sensors-detect.err && echo 'no diagnostic output on stderr'

The transcript contains hardware information. Store it according to your local information-handling rules and remove it when it is no longer needed:

$ rm -- sensors-detect.out sensors-detect.err

5. Load a module only after review

sensors-detect detects chips; it does not make every suggested module a safe production choice. Before changing the running kernel, check the module name and whether the distribution already loads it through its normal lm-sensors integration. If you do load one manually, use the exact name printed for this host and keep a console session open:

$ sudo modprobe MODULE_NAME
$ sensors

Replace MODULE_NAME with the reviewed value from your own scan. modprobe changes kernel state and requires elevated privileges. Stop if it reports an error, if the machine becomes unstable, or if readings look implausible. Record the old state before changing anything:

$ lsmod > modules-before.txt
$ sudo modprobe MODULE_NAME
$ sensors | tee sensors-after.txt

$ sudo modprobe -r MODULE_NAME

Do not remove a module that other devices depend on. Check the dependency list and the service or boot configuration before attempting a persistent rollback. A reboot may be the safest recovery for a workstation, but use your platform's documented recovery process for a remote system.

6. Verify what actually works

Run sensors as an ordinary user after the reviewed module is loaded:

$ sensors
chip-name-isa-0000
Adapter: ISA adapter
temperature:  +42.0°C  (high = +80.0°C, crit = +100.0°C)

The chip label and fields differ by hardware, and some boards report voltage or fan values instead of temperature. Do not treat a plausible number as proof that a sensor is calibrated. Compare it with firmware readings or a known workload, and investigate values that are missing, fixed at an extreme, or inconsistent with the machine's physical state.

A successful scan does not guarantee that a module is loaded, that every sensor is exposed, or that the readings are accurate. Use the transcript, lsmod, and sensors output together when diagnosing a missing reading.