Bug 2186601

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.