Summary
- OS: Linux
- Architecture: x86_64
- Psutil version: 7.2.2
- Python version: 3.14.6
- Type: core
Description
On my own computer I noticed that applications like s-tui parse and use the alarm thresholds from psutil even if they definitely show negative placeholder values, resulting in alarms being triggered despite temperatures being okay.
psutil.sensors_temperatures() reads high and critical alarm thresholds from sysfs files like /sys/class/hwmon/*/temp*_max and temp*_crit. On many platforms these files hold a placeholder value when no threshold is configured. Psutil divides by 1000 and returns the sentinel as if it were a real alarm threshold.
In my specific case, the CROS EC / F75303 thermal drivers on my Framework 16 (and likely other ChromeOS devices) show -273150 (absolute zero in milli-degrees Celsius) via these files. This doesn't just seem to happen on my computer but also seems to have tripped up an assertion in #2551 (though in that case the current value was unset, not an alert threshold).
Summary
Description
On my own computer I noticed that applications like s-tui parse and use the alarm thresholds from psutil even if they definitely show negative placeholder values, resulting in alarms being triggered despite temperatures being okay.
psutil.sensors_temperatures()readshighandcriticalalarm thresholds from sysfs files like/sys/class/hwmon/*/temp*_maxandtemp*_crit. On many platforms these files hold a placeholder value when no threshold is configured. Psutil divides by 1000 and returns the sentinel as if it were a real alarm threshold.In my specific case, the CROS EC / F75303 thermal drivers on my Framework 16 (and likely other ChromeOS devices) show
-273150(absolute zero in milli-degrees Celsius) via these files. This doesn't just seem to happen on my computer but also seems to have tripped up an assertion in #2551 (though in that case the current value was unset, not an alert threshold).