SensorsTemperatures should provide a unique sensor identity

[danielnelson]

Describe the bug This issue is somewhere between a bug report and a feature request. When using the host.SensorsTemperatures() call it is possible for multiple TemperatureStat objects to have the same SensorKey. In order to distinguish temperature sensors and in particular when making multiple calls over time, it would be useful if we could guarantee each sensor will have a unique sensor key or provide an additional field that would be unique and not change between calls.

To Reproduce

package main

import (
        "fmt"

        "github.com/shirou/gopsutil/host"
)

func main() {
        sensors, err := host.SensorsTemperatures()
        if err != nil {
                fmt.Println(err)
        }

        for _, s := range sensors {
                fmt.Printf("%+v\n", s)
        }
}

Output:

$ go run cmd/temp/main.go
{"sensorKey":"acpitz_crit","sensorTemperature":128}
{"sensorKey":"acpitz_input","sensorTemperature":46}
{"sensorKey":"coretemp_packageid0_crit","sensorTemperature":100}
{"sensorKey":"coretemp_packageid0_critalarm","sensorTemperature":0}
{"sensorKey":"coretemp_packageid0_input","sensorTemperature":50}
{"sensorKey":"coretemp_packageid0_max","sensorTemperature":100}
{"sensorKey":"coretemp_core0_crit","sensorTemperature":100}
{"sensorKey":"coretemp_core0_critalarm","sensorTemperature":0}
{"sensorKey":"coretemp_core0_input","sensorTemperature":47}
{"sensorKey":"coretemp_core0_max","sensorTemperature":100}
{"sensorKey":"coretemp_core1_crit","sensorTemperature":100}
{"sensorKey":"coretemp_core1_critalarm","sensorTemperature":0}
{"sensorKey":"coretemp_core1_input","sensorTemperature":49}
{"sensorKey":"coretemp_core1_max","sensorTemperature":100}
{"sensorKey":"iwlwifi_input","sensorTemperature":30}

Expected behavior Each sensor should have a unique SensorKey or way of identification.

Environment (please complete the following information):

• [ ] Windows: [paste the result of ver]
• [x] Linux: [paste contents of /etc/os-release and the result of uname -a]
• [ ] Mac OS: [paste the result of sw_vers and uname -a
• [ ] FreeBSD: [paste the result of freebsd-version -k -r -u and uname -a]
• [ ] OpenBSD: [paste the result of uname -a]

$ cat /etc/os-release 
NAME=Gentoo
ID=gentoo
PRETTY_NAME="Gentoo/Linux"
ANSI_COLOR="1;32"
HOME_URL="https://www.gentoo.org/"
SUPPORT_URL="https://www.gentoo.org/support/"
BUG_REPORT_URL="https://bugs.gentoo.org/"

$ uname -a
Linux loaner 4.19.97-gentoo #2 SMP Mon Feb 10 01:05:38 PST 2020 x86_64 Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz GenuineIntel GNU/Linux

Additional context

$ for x in /sys/class/hwmon/hwmon2/temp*_*; do echo $x; cat $x; done
/sys/class/hwmon/hwmon2/temp1_crit
100000
/sys/class/hwmon/hwmon2/temp1_crit_alarm
0
/sys/class/hwmon/hwmon2/temp1_input
45000
/sys/class/hwmon/hwmon2/temp1_label
Package id 0
/sys/class/hwmon/hwmon2/temp1_max
100000
/sys/class/hwmon/hwmon2/temp2_crit
100000
/sys/class/hwmon/hwmon2/temp2_crit_alarm
0
/sys/class/hwmon/hwmon2/temp2_input
43000
/sys/class/hwmon/hwmon2/temp2_label
Core 0
/sys/class/hwmon/hwmon2/temp2_max
100000
/sys/class/hwmon/hwmon2/temp3_crit
100000
/sys/class/hwmon/hwmon2/temp3_crit_alarm
0
/sys/class/hwmon/hwmon2/temp3_input
44000
/sys/class/hwmon/hwmon2/temp3_label
Core 1
/sys/class/hwmon/hwmon2/temp3_max
100000

[gsauthof]

I don't know if it's obvious from the above example how the current code produces non-unique keys.

On a multi-socket system, the core specific sensors get non-unique keys like this:

# socket 0
coretemp_core0_input
coretemp_core1_input
...
# socket 1
coretemp_core0_input
coretemp_core1_input
...

[Lomanic]

What is the result of python -c "import psutil; print psutil.sensors_temperatures()" (after a pip install psutil) on a multi-socket machine? I don't have any for testing unfortunately.

[gsauthof]

Python psutil returns non-unique labels.

In addition, it duplicates the sensors. From strace output I can see that it traverses /sys/class/hwmon/hwmon* and /sys/devices/platform/coretemp.*/hwmon/hwmon* perhaps this leads to the duplication.

I tested with Python 3 and the current psutil (i.e. what was available on PyPi a few days ago).

Command:

python -c 'import psutil; 
        print("\n".join(f"{x.label} {x.current}"
                 for x in psutil.sensors_temperatures()["coretemp"]))'  \
    | sed 's/ id/_id/' | column -t

Example output (from a 2 socket machine with 8 cores each, no hyperthreading available):

Physical_id  0   69.0
Core         16  57.0
Core         0   69.0
Core         19  57.0
Core         20  61.0
Core         22  58.0
Core         4   56.0
Core         5   57.0
Core         6   61.0
Physical_id  1   65.0
Core         9   57.0
Core         16  54.0
Core         0   57.0
Core         19  56.0
Core         26  54.0
Core         27  54.0
Core         2   65.0
Core         3   56.0
Physical_id  0   69.0
Core         16  57.0
Core         0   69.0
Core         19  57.0
Core         20  61.0
Core         22  58.0
Core         4   56.0
Core         5   57.0
Core         6   61.0
Physical_id  1   65.0
Core         9   57.0
Core         16  54.0
Core         0   57.0
Core         19  56.0
Core         26  54.0
Core         27  54.0
Core         2   65.0
Core         3   56.0

Note also how the core numbers don't make sense (e.g. lscpu//proc/cpuinfo uses range 0-15).

I tested this on a few multi-socket machines and the output it similar for different hardware generations/vendors.