Description of problem: Thermal zone sensor selection does not persist in the system-monitor-applet GNOME Shell extension. Version-Release number of selected component (if applicable): gnome-shell-extension-system-monitor-applet-38-22.20230326git21d7b4e.fc37.noarch How reproducible: Always Steps to Reproduce: 1. Enable thermal zone display and set sensor to anything, e.g. 'coretemp - Package id 0' 2. Restart the machine 3. Log back in 4. Check the thermal sensor display Actual results: --°C Expected results: Actual value (e.g. 42°C). Additional info: When I go back to settings, no sensor is selected in the Thermal tab.
Hello, Thank you for reporting this issue. There seems that the problem you encountered needs probably to be reported upstream: https://github.com/paradoxxxzero/gnome-shell-system-monitor-applet/issues But, in the meantime, maybe we could try to catch this issue by our own. For my part, I didn't encountered this bug on my laptop or the stations I work with. All the settings of this gnome-shell extension can be seen/modified by its dedicated user interface, but also with dconf-editor. In dconf-editor, you should find and edit the concerned parameter in this place (use with caution): /org/gnome/shell/extensions/system-monitor/thermal-sensor-file You can also get this parameter through the console with a command line like: gsettings get org.gnome.shell.extensions.system-monitor thermal-sensor-file This should show you the actual settings by printing the path to the file containing the values computed by the extension. For example, on my configuration, the monitored file is: /sys/class/hwmon/hwmon1/temp1_input It is shown as 'acpitz - 1' in the gnome-shell extension user interface. This name is extracted from the file 'name' in the same directory containing the target file 'temp1_input' and completed with a dash and a number (an index). Could you please check that the file shown as 'coretemp - Package id 0' in your settings user interface is accessible in the file system tree (dconf or gsettings would be helpful to get its path and name). Maybe some authorizations are missing, or the file is not accessible while your session opens. Maybe the command: ls -lZ /path_to_that/file should be of any help (the -Z commutator shows the SeLinux authorizations). Feel free to make any comment about this. I keep thinking about this issue and get back to you shortly, if any light appears. Cordially, -- NVieville
Created attachment 1957939 [details] missing temperature readout from thermal sensor Ok, I was able to reproduce it this morning (machine suspended yesterday afternoon and resumed this morning) and it's actually stranger than I thought. The gsettings setting is there: $ gsettings get org.gnome.shell.extensions.system-monitor thermal-sensor-file '/sys/class/hwmon/hwmon3/temp1_input' However, the temperature is not displayed (see attached). That's probably because the sensor is now missing: $ cat /sys/class/hwmon/hwmon3/temp1_input cat: /sys/class/hwmon/hwmon3/temp1_input: No such file or directory If I select the same 'coretemp - Package id 0' sensor now, I get a different sensor path: $ gsettings get org.gnome.shell.extensions.system-monitor thermal-sensor-file '/sys/class/hwmon/hwmon4/temp1_input' However, subsequent (short) suspend/resume cycles don't reproduce the issue. So, weird.
Hello, Thank you for your response. It seems to confirm what this page says: https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface.rst 'Note that motherboards vary widely in the connections to sensor chips. There is no standard that ensures, for example, that the second temperature sensor is connected to the CPU, or that the second fan is on the CPU.' The identification of the sensors (order of their respective numbers) depends on the manufacturers and the load speed of their drivers. That last one is probably the reason why one sensor doesn't have always the same identity across different reboots on a same machine. For my part, I never encountered the problem you described, may be the sensors and the CPU of my laptop are too slow while booting to achieve their initialization to race against each other and switch their ids. This page attempts to fix manually the problem by adding udev rules after identifying the right sensors: https://joonas.fi/2021/07/stable-device-path-for-linux-hwmon-interfaces/ May be a path to the solution. I don't know if this is worth opening an " issue " or a " feature request " upstream to try to get some robust code that gives consistent results across reboots. Don't know if other tools dealing with sensors have resolved this sort of problem. Feel free to make any comment about these subjects. Cordially, -- NVieville
Thanks for the detailed response, Nicolas. I guess it does make sense to report this upstream directly and I'll do that as time permits.
FWIW, lm_sensors shows descriptive names and one can parse its JSON output to get values consistently: $ sensors -j | jq '.["f71889a-isa-0290"]["CPU fan"].fan1_input' 1075.000 $ sensors -j | jq '.["coretemp-isa-0000"]["Package id 0"].temp1_input' 42.000
I guess this is the relevant upstream issue.