Cockpit: Feature request: monitor CPU temperature

[yunchih]

I would like to monitor the temperature on my embedded devices. It'd be good if it is displayed as a graph, just like CPU, memory usage.

[stefwalter]

Is this feasible?
What are the right files to look for?
Thanks ( ;

Step 1 is to build a prototype. Here are some examples of tutorials for implementing a part of the interface in Cockpit. These will help you get started with a prototype:

• https://matrixhas.me/en/creating-cockpit-plugin/
• http://cockpit-project.org/blog/creating-plugins-for-the-cockpit-user-interface.html
• http://cockpit-project.org/blog/category/tutorial.html

Once you have a prototype working, Step 2 is to have the UI designed by @andreasn or another designer. He'll help think about where it should show up in the UI.

[yunchih]

Thanks for the guide. I will try to work on this.

[yunchih]

It seems that if thermal graph is installed as a plugin, it would be placed under the Tools tab as a separate subtab.
It'd be great if the thermal graph is displayed in continuous form just like CPU and memory; and viewed as a system health indicator parallel to CPU, memory, disk and network. That is, instead of placing it in a separate tab, place it in the system and dashboard tab and integrate it with our current four system metrics.
That might involves:

1. adding libsensors as a dependency to collect thermal statistics.
2. adding sampler/bridge in src/bridge.

Any suggestion about feasibility? Or could it conflict with project ideal?

[stefwalter]

It seems that if thermal graph is installed as a plugin, it would be placed under the Tools tab as a separate subtab.

Yes. That's where the prototype goes.

It'd be great if the thermal graph is displayed in continuous form just like CPU and memory; and viewed as a system health indicator parallel to CPU, memory, disk and network. That is, instead of placing it in a separate tab, place it in the system and dashboard tab and integrate it with our current four system metrics.

For any new area like this, first we build a prototype, and then once it is working @andreasn would help come up with a design to integrate it deeper into the main page.

That might involves:
adding libsensors as a dependency to collect thermal statistics.
adding sampler/bridge in src/bridge.

We already have PCP gathering information is the information available in PCP?

Or secondly, the information seems to be available in /sys. Does it make sense to add another internal sampler to cockpit-bridge that retrieves the information from /sys? I see this:

[stef@falcon cockpit]$ find /sys/ -name '*temp*'
find: ‘/sys/kernel/debug’: Permission denied
/sys/devices/platform/coretemp.0
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp5_crit
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp3_crit_alarm
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp4_crit
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp1_max
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp5_max
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp3_label
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp2_input
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp3_crit
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp5_input
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp4_crit_alarm
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp2_crit
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp2_max
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp5_crit_alarm
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp1_label
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp4_label
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp1_crit
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp3_input
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp3_max
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp1_crit_alarm
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp2_label
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp1_input
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp2_crit_alarm
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp5_label
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp4_input
/sys/devices/platform/coretemp.0/hwmon/hwmon2/temp4_max
/sys/devices/virtual/hwmon/hwmon0/temp2_input
/sys/devices/virtual/hwmon/hwmon0/temp2_crit
/sys/devices/virtual/hwmon/hwmon0/temp1_crit
/sys/devices/virtual/hwmon/hwmon0/temp1_input
/sys/devices/virtual/thermal/thermal_zone1/trip_point_1_temp
/sys/devices/virtual/thermal/thermal_zone1/trip_point_0_temp
/sys/devices/virtual/thermal/thermal_zone1/temp
/sys/devices/virtual/thermal/thermal_zone2/trip_point_1_temp
/sys/devices/virtual/thermal/thermal_zone2/trip_point_0_temp
/sys/devices/virtual/thermal/thermal_zone2/temp
/sys/devices/virtual/thermal/thermal_zone0/trip_point_5_temp
/sys/devices/virtual/thermal/thermal_zone0/trip_point_4_temp
/sys/devices/virtual/thermal/thermal_zone0/trip_point_3_temp
/sys/devices/virtual/thermal/thermal_zone0/trip_point_2_temp
/sys/devices/virtual/thermal/thermal_zone0/trip_point_1_temp
/sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp
/sys/devices/virtual/thermal/thermal_zone0/temp
/sys/bus/platform/devices/coretemp.0
/sys/bus/platform/drivers/coretemp
/sys/bus/platform/drivers/coretemp/coretemp.0
/sys/module/x86_pkg_temp_thermal
/sys/module/coretemp
/sys/module/coretemp/drivers/platform:coretemp

See src/bridge/cockpitmemorysamples.c for an example of how to build such a sampler. Or if that seems out of reach, you identify exactly the /sys files that you would like to reflect in the sampler, and then I could help build the sampler part.

Any suggestion about feasibility? Or could it conflict with project ideal?

We wouldn't want to link to a new library dependency to Cockpit itself, so either:

• There is an already existing DBus or socket API for this info ... or
• We use PCP to gather the info ... or
• Or we build an internal sampler that reads /sys

Does that make sense?

[stefwalter]

CC @mvollmer

[stefwalter]

More information about coretemp module that shows up in /sys: https://www.kernel.org/doc/Documentation/hwmon/coretemp

[yunchih]

Thank!! I'll look into that.
It seems that /sys/class/thermal/thermal_zone0/temp could be a right place, at least for my x86-64 and arm devices.

[andreasn]

I think the CPU details page that you can reach from the server page sounds like a natural place for this. I'm not sure it's critical enough to enough people to display on the frontpage itself (apart from maybe the current temperature), but certainly on the CPU-page.

[yunchih]

Great suggestion. I think I'll try to build a prototype first, starting from a bridge which parses /sys/class/thermal/*.

[Sadin]

Any progress on this? Also have you considered how/what the module will display if cockpit is installed on say a VPS?

[syntax402]

This would be a great addition - and especially useful on the front-page (dashboard). Either a graph or simple CPU temp in Celcius would be perfect.

[larskarlitski]

This has been open for a while with no activity and little detail, so I'm closing it now.

I still think this is a great idea. Doesn't seem like that much work, because PCP can output that information.

[JamesGKent]

@larskarlitski I'd be interested in implementing this, I'm reading through the documentation and trying to understand what I need to do.
you have stated that PCP can output that information but PCP may not always be present, and i also can't work out how to query that even if it was.
I believe we can have multiple ways of querying the same information? eg use PCP if available, fall back to DBus query of thermald if present, and if not fall back to using the /sys/devices/platform to query what is available?

obviously the directory scraping should really not be done via websocket calls to ls etc, so where should this code reside?

[MRsagi]

I'm pretty new around here but I managed to do some simple solution.
Surprising nobody did it until now

I uploaded it to here:
https://github.com/MRsagi/cockpit-temperature-plugin

[maddis4free]

@MRsagi
nice plugin, but only works it for raspi. could you provide a plugin for a debian buster - system?

rgds

[MRsagi]

@maddis4free thanks for the interest!
You can replace the code in the cockpit.spawn to something like this:

pi@raspberrypi:~ $ cat /sys/class/thermal/thermal_zone0/temp
46251

just don't forget to divide by 1000. In this example the temperature is 46.251*C

[kanadaj]

For anyone else wanting to install this plugin; if you install lm_sensors, on the host system replace the bit from https://github.com/MRsagi/cockpit-temperature-plugin/blob/08fe3119387c9647046d3a344030855cca88826f/temperature.js#L13 with the following script call to get a sensor reading from sensors and find the line you want:

var proc = cockpit.script("sensors | grep Tctl | awk '{print $2}'");

Replace grep Tctl with whichever line you want to read from the sensors output.

[dannygils]

For anyone else wanting to install this plugin; if you install lm_sensors, on the host system replace the bit from https://github.com/MRsagi/cockpit-temperature-plugin/blob/08fe3119387c9647046d3a344030855cca88826f/temperature.js#L13 with the following script call to get a sensor reading from sensors and find the line you want:

var proc = cockpit.script("sensors | grep Tctl | awk '{print $2}'");

Replace grep Tctl with whichever line you want to read from the sensors output.

Tried your suggestion above, my only correction - instead of using $2, use $3

$ sensors | grep 'Core 1' | awk '{print $2}'
$ 1:

$ sensors | grep 'Core 1' | awk '{print $3}'
$ +66.0°C

Additionally, if you're as frustrated by the amount of numbers after the decimal place, edit line 15:

pt = parseInt(data.match(/([0-9\.]+)/)[1]);

and line 41:

 return parseInt(sum / count);

[kanadaj]

@dannygils There might be a difference in output between different versions or different OS's; on Fedora, the output of sensors | grep Tctl is as follows:

Tctl:         +53.0°C

That's only 2 terms, so I suspect it's either a difference in versions or sensor modules, but a good catch anyway! This should make it easier to monitor CPU temps on non-raspberry systems

[dannygils]

@dannygils There might be a difference in output between different versions or different OS's; on Fedora, the output of sensors | grep Tctl is as follows:

Tctl:         +53.0°C

That's only 2 terms, so I suspect it's either a difference in versions or sensor modules, but a good catch anyway! This should make it easier to monitor CPU temps on non-raspberry systems

@kanadaj that's really interesting. I'm on Fedora 30, and my sensors output looks like:

(Fri Apr-4 2:22:50pm)-(CPU 10.6%:0:Net 9)-(304K:38)
> sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +46.0°C  (high = +100.0°C, crit = +100.0°C)
Core 0:        +45.0°C  (high = +100.0°C, crit = +100.0°C)
Core 1:        +45.0°C  (high = +100.0°C, crit = +100.0°C)

nvme-pci-3c00
Adapter: PCI adapter
Composite:    +39.9°C  (low  = -273.1°C, high = +76.8°C)
                       (crit = +78.8°C)
Sensor 1:     +39.9°C  (low  = -273.1°C, high = +65261.8°C)
Sensor 2:     +42.9°C  (low  = -273.1°C, high = +65261.8°C)

iwlwifi_1-virtual-0
Adapter: Virtual device
temp1:        +46.0°C

pch_skylake-virtual-0
Adapter: Virtual device
temp1:        +49.0°C

I've made a fork of @MRsagi work in case there are others out there interested in using his plugin on non-raspberries :)

[kanadaj]

Oh my bad it was actually measuring the PCI card, it can't read the CPU temp for some reason, probably needs an extra module to read the temps on AMD