Best practice CPU temp monitoring: -current

I have a new computer build and I am keen to watch the CPU temp while I am getting used to it and the AIO cooler I have installed. At the moment I am using conky with:

${color black}CPU Temp:${alignr}${execi 10 cat /sys/class/hwmon/hwmon0/temp1_input | cut -c 1-2}°C

Does this seem reasonable to more experienced users? This certainly tracks rise and fall pretty accurately. I had a look at sensors but I do not understand the output:

andrew@ilium~$ sensors
k10temp-pci-00c3
Adapter: PCI adapter
Tdie:         +21.8°C  (high = +70.0°C)
Tctl:         +48.8°C  

k10temp-pci-00cb
Adapter: PCI adapter
Tdie:         +21.5°C  (high = +70.0°C)
Tctl:         +48.5°C  

andrew@ilium~$

Thanks...

I use glances for monitoring my system in real time. If you're running KDE then ksysguard can be configured to monitor what you want.

Originally Posted by 3rensho I use glances for monitoring my system in real time. If you're running KDE then ksysguard can be configured to monitor what you want.

I confess that I had not heard of either of these and a quick inspection shows that they both make conky look a little 'old school'

I just upgraded psutil to 5.6.3 and glances reports diskio now.

Another way to get that info without having to use cat / shell commands is to use hwmon in your conky config. Should be more efficient than execi.


Something like:

${hwmon 0 temp 1}

http://conky.sourceforge.net/variables.html

Hwmon sensor from sysfs (Linux 2.6). Parameter dev may be omitted if you have only one hwmon device. Parameter type is either 'in' or 'vol' meaning voltage; 'fan' meaning fan; 'temp' meaning temperature. Parameter n is number of the sensor. See /sys/class/hwmon/ on your local computer. The optional arguments 'factor' and 'offset' allow precalculation of the raw input, which is being modified as follows: 'input = input * factor + offset'. Note that they have to be given as decimal values (i.e. contain at least one decimal place).

used gkrellm for years give it a try

conky/gkrellm will show temperatures in real time as mentioned above. But I don't think you are happy with the idea of wasting your life staring at the monitor to watch that :-)

Additionally, run something that tracks temperature and saves it over time, so you could fire up a web browser and have a look at a graph for a long period of time whenever you need. You'll have to investigate because there's plenty of options. It can be an enterprise-scale behemoth like nagios/zabbix, collectd with sensors plugin enabled, or something more lightweight to run on a desktop. My personal favorite is monitorix. SBo has a buildscript for it. I can get daily/weekly/monthly/yearly graphs there for a lot of things, including CPU temperatures.

Like a dog with a bone I cannot let go of this thread . Spurred along by some undoubtedly spurious temps generated with kernel 5.7.x and 5.8 I have had a closer look at lm-sensors and hopefully sorted out a more definitive CPU temperature monitoring. With lm-sensors configured properly and the appropriate modules loaded I have the following:

andrew@ilium~$ sensors
nct6797-isa-0a20
Adapter: ISA adapter
in0:                   768.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:                   1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                     3.33 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                     3.31 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                     1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                   144.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                   944.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                     3.33 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                     3.23 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                     1.82 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                  680.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                  648.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                    1.15 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                  680.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                    1.51 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                     0 RPM  (min =    0 RPM)
fan2:                  2073 RPM  (min =    0 RPM)
fan3:                     0 RPM  (min =    0 RPM)
fan4:                     0 RPM  (min =    0 RPM)
fan5:                     0 RPM  (min =    0 RPM)
fan6:                     0 RPM  (min =    0 RPM)
fan7:                   851 RPM  (min =    0 RPM)
SYSTIN:                 +32.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = CPU diode
CPUTIN:                 +27.0°C  (high = +107.0°C, hyst = +89.0°C)  sensor = thermistor
AUXTIN0:                +29.0°C  (high = +107.0°C, hyst = +89.0°C)  sensor = thermistor
AUXTIN1:                +44.0°C    sensor = thermistor
AUXTIN2:                +46.0°C    sensor = thermistor
AUXTIN3:                 -1.0°C    sensor = thermistor
SMBUSMASTER 0:          +53.0°C  
PCH_CHIP_CPU_MAX_TEMP:   +0.0°C  
PCH_CHIP_TEMP:           +0.0°C  
PCH_CPU_TEMP:            +0.0°C  
intrusion0:            ALARM
intrusion1:            ALARM
beep_enable:           disabled

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +53.0°C  
Tdie:         +26.0°C  
Tccd1:        +52.5°C  

k10temp-pci-00cb
Adapter: PCI adapter
Tctl:         +52.5°C  
Tdie:         +25.5°C  

andrew@ilium~$

The temp that has drawn my attention is CPUTIN which I believe is CPU temp reported by the motherboard and I have added this to ~/.conkyrc with:

CPU Temp:${alignr}${execi 10 sensors | grep CPUTIN | cut -d '+' -f 2 | cut -d ' ' -f1}

But I guess the issue is that there can never really be a definitive method of monitoring CPU temp as there will be too much variability with available sensors, mobo types, Linux kernel and even installed version of lm-sensors. Fascinating though

On a rainy weekend I will work on that syntax a little as a 'serial' cut command is never the most efficient way of doing things...

Originally Posted by coralfang Another way to get that info without having to use cat / shell commands is to use hwmon in your conky config. Should be more efficient than execi. Something like: ${hwmon 0 temp 1} http://conky.sourceforge.net/variables.html

coralfang is right, this is the correct way to monitor CPU temps with conky. This way will give you real time monitoring.

Originally Posted by Daedra coralfang is right, this is the correct way to monitor CPU temps with conky. This way will give you real time monitoring.

I really don't see any justification for calling one method correct over another especially when the kernel dev team specifically recommends lm-sensors to interpret hwmon. They act essentially the same with the same API but "sensors" is specific to the chipset kernel modules and labels it's reports.

I've used bare lm-sensors, gkrellm (which is a rather old and clunky interface) and conky. Conky requires knowing some code instead of just selecting someone else's work as a kind of module with very minor specifics in how much is reported in what fields. GKrellm works and is a perfectly fine choice but it does show it's age and limitations in display. Conky is definitely more flexible and individual, even if it is sometimes a pita but that's actually because of the many variations in WM/DEs.

Presently and for a few years now I've been using this format for CPU temps in real time

  ###Conky CPU Temps
###core temps
###
${offset 400}${color red}${exec sensors | grep 'Core 0' | awk '{print $0,$1,$2,$3}'| cut -c1-24} 
${offset 410}${color red}${exec sensors | grep 'Core 1' | awk '{print $0,$1,$2,$3}'| cut -c1-24}
${offset 420}${color red}${exec sensors | grep 'Core 2' | awk '{print $0,$1,$2,$3}'| cut -c1-24}
${offset 430}${color red}${exec sensors | grep 'Core 3' | awk '{print $0,$1,$2,$3}'| cut -c1-24}
###

It works just fine

To get an approximate idea instead of exact degrees, I use the bar:

CPU Temp:  ${execibar 10 echo \
  $((`cat /sys/devices/platform/coretemp.0/hwmon/hwmon0/temp1_input`/1000))}

Originally Posted by enorbet I really don't see any justification for calling one method correct over another especially when the kernel dev team specifically recommends lm-sensors to interpret hwmon. They act essentially the same with the same API but "sensors" is specific to the chipset kernel modules and labels it's reports. I've used bare lm-sensors, gkrellm (which is a rather old and clunky interface) and conky. Conky requires knowing some code instead of just selecting someone else's work as a kind of module with very minor specifics in how much is reported in what fields. GKrellm works and is a perfectly fine choice but it does show it's age and limitations in display. Conky is definitely more flexible and individual, even if it is sometimes a pita but that's actually because of the many variations in WM/DEs. Presently and for a few years now I've been using this format for CPU temps in real time ###Conky CPU Temps ###core temps ### ${offset 400}${color red}${exec sensors | grep 'Core 0' | awk '{print $0,$1,$2,$3}'| cut -c1-24} ${offset 410}${color red}${exec sensors | grep 'Core 1' | awk '{print $0,$1,$2,$3}'| cut -c1-24} ${offset 420}${color red}${exec sensors | grep 'Core 2' | awk '{print $0,$1,$2,$3}'| cut -c1-24} ${offset 430}${color red}${exec sensors | grep 'Core 3' | awk '{print $0,$1,$2,$3}'| cut -c1-24} ### It works just fine

I didn't mean to insinuate one way is wrong over another. What I mean is that conky devs and users generally accept ${hwmon 0 temp 1} is the most universally excepted way to get real time monitoring of CPU temps. But conky is not picky, if it works it works.