Excessive or just elevated temperature is sometimes the source of unexpected behavior in computing components – I faced it firsthand once, with runaway CPU heat burning through an older Slot I Pentium 3 processor. The cause was a detached heat sink, and some older hardware did not have built-in protection circuitry back then. I have also had fun experiencing intriguing boot failures from an overheating hard drive in a system equipped with one too many peripherals. In recent times I have taken a more preemptive stance, monitoring the heat build-up in a Raspberry Pi cluster as the case fan was replaced (Figure 1) [1]. To silence a desktop cluster, I replaced the built-in fan with a slower, silent fan made by specialty vendor Noctua [2]. Because the newer fan used fewer revolutions per minute to get the job done, I had to verify that the temperature inside the case remained roughly the same after the change:

vcgencmd measure_temp

Figure 1: Raspberry Pi 4 Picocluster in testing.

The output quickly demonstrated that the temperature remained within the same range it had with the older fan. The vcgencmd utility is a tool made by Broadcom to access the state of the VideoCore GPU found on all Raspberry Pi boards [3]. It can also provide insight into voltage levels for cores and SDRAM, among other things, which can come handy while troubleshooting heat problems (Figure 2).

Figure 2: vcgencmd extracting temperature and voltage information from a Raspberry Pi GPU. Note the use of parallel SSH syntax to access all nodes in a cluster.

Terminal UI Redux

Returning to a common topic on these pages, an interesting example of a terminal user interface (TUI) [4] for the Mac is the istats tool (install from Ruby Gems with gem install iStats) [5]. iStats provides convenient access to temperature, battery, and fan speed data on macOS systems (Figure 3). Its simple and easy-to-use interface belies a hidden complexity. The istats scan command will look for additional "keys" of sensor data available on a given system and offer to enable them at the user's discretion (Figure 4).

Figure 3: iStats at work on a Mac. The chart of the number of battery cycles of this old battery is actually blinking in red!

Figure 4: iStats scanning sensors available on an older MacBook Pro. Not all values discovered are temperatures.

On Linux, my default choice for in-terminal monitoring TUI is glances  [6], which I have examined previously for its many capabilities [7]. Yet, I did not look at its temperature module, an oversight Figure 5 now aims to remedy. Data is sourced from the sensors [8] command (apt install lm-sensors), which is a configurable, consistent command-line interface gathering the multitude sensor data exposed by a disparate array of Linux kernel modules (Listing 1; from the same system on which glances was run). Indeed, if this tour of sensor tools and interfaces has shown one thing, it is that the variety of sensor data available is highly variable. Ranging from a Raspberry Pi, to a vintage MacBook Pro, to an HP Microserver, every system has provided different datasets. Often the biggest challenge is correctly identifying the source of the data, which can originate in a CPU, a GPU, a management card, and a variety of alternative sources.

federico@ferenginar:~$ sensors
k10temp-pci-00c3
Adapter: PCI adapter
temp1:        +42.5¡C  (high = +70.0¡C)
                       (crit = +100.0¡C, hyst = +95.0¡C)
federico@ferenginar:~$

Figure 5: glances presents temperature data on its left-hand panel whenever it is available.

Let There Be Dell

Switching to a fourth system, this one running Linux on an Intel processor, I can make use of i7z [9], a tool explicitly written to visualize the state of Intel processors  – including their temperature. Figure 6 shows the results on an Intel Core-equipped laptop. The more general purpose solution is to configure lm-sensors to include kernel modules for all sensors available, which is done through the sensors-detect command in a way akin to what was previously described for iStats. With lm-sensors, you can actually configure the kernel to load the correct modules at boot time, as recently described by our own Bruce Byfield in sister publication Linux Magazine [10]. Once this configuration step is successfully accomplished, all data for a specific system becomes available in the usual filesystem locations (usually in /sys/), ready to be consumed by higher level programs (Figure 7).

Figure 6: i7z at work, constantly refreshing CPU state data, including temperatures.

Figure 7: The complete range of sensors available on a Dell XPS 13 9360 "Sputnik."

One such example is psensor [11], a GUI application charting select metrics and sensors to facilitate time series analysis. Not perfectly polished in its windowing toolkit interactions, at least in Ubuntu 22.04, it nonetheless remains the best option currently available (Figure 8).

Figure 8: psensor charting some of the sensors listed in Figure 7.

Disk Sensors

The all-purpose smartctl utility offers storage device temperature data (apt install smartmontools) [12] equally well for spinning media and solid-state NVMe storage (Listing 2; from a persistent storage SMART source). It is generally advisable to maintain storage media under 60¡C (140¡F), with the actual drive's specification having the final say.

federico@voronoi:~$ sudo smartctl -A /dev/nvme0 | grep Temperature
[sudo] password for federico:
Temperature:                        42 Celsius
Warning  Comp. Temperature Time:    16
Critical Comp. Temperature Time:    28
Temperature Sensor 1:               42 Celsius
federico@voronoi:~$