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.

This message is a reminder that Fedora Linux 37 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '37'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 37 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 37 entered end-of-life (EOL) status on 2023-12-05.

Fedora Linux 37 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

This is still an issue on F40. It looks like it was fixed upstream, too:
https://github.com/mgalgs/gnome-shell-system-monitor-applet/pull/73

Nicolas, could you make an update to a more recent snapshot? It looks
like the packaged version is based on
4a1cfff514dc4feeaef8727ceed008029d01fed7 from April 22nd, while the fix
for this bug landed in subsequent commits. I.e. please update to the
current master branch HEAD (4bd03a2944f124a493ab8fe0df757c45f00b9c81).

I opened a PR: https://src.fedoraproject.org/rpms/gnome-shell-extension-system-monitor-applet/pull-request/1 .

FEDORA-2024-5cc3b12a7c (gnome-shell-extension-system-monitor-applet-38-30.20240717git4bd03a2.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-5cc3b12a7c

FEDORA-2024-5cc3b12a7c (gnome-shell-extension-system-monitor-applet-38-30.20240717git4bd03a2.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.

Hello Dominik,

> This is still an issue on F40. It looks like it was fixed upstream, too:
> https://github.com/mgalgs/gnome-shell-system-monitor-applet/pull/73

Thank you very much for your heads-up.

> Nicolas, could you make an update to a more recent snapshot? It looks
> like the packaged version is based on
> 4a1cfff514dc4feeaef8727ceed008029d01fed7 from April 22nd, while the fix
> for this bug landed in subsequent commits. I.e. please update to the
> current master branch HEAD (4bd03a2944f124a493ab8fe0df757c45f00b9c81).

Sure. Since April 22, I've been tracking commits in the github upstream
repository on the sensors issue, but I have to admit that this fell 
under my radar before it was finished :-).

> I opened a PR:
> https://src.fedoraproject.org/rpms/gnome-shell-extension-system-monitor-
> applet/pull-request/1 .

Thank you very much for that. Sorry for not using it, but I had to add
few more comments in the log section of the SPEC file.

Thank you again for your vigilance on this bug report.

Cordially,


-- 
NVieville

FEDORA-2024-f81e2b65fe (gnome-shell-extension-system-monitor-applet-38-30.20240717git4bd03a2.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-f81e2b65fe

FEDORA-2024-b9b80eacd5 (gnome-shell-extension-system-monitor-applet-38-30.20240717git4bd03a2.fc39) has been submitted as an update to Fedora 39.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-b9b80eacd5

FEDORA-2024-b9b80eacd5 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-b9b80eacd5`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-b9b80eacd5

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-f81e2b65fe has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-f81e2b65fe`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-f81e2b65fe

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-f81e2b65fe (gnome-shell-extension-system-monitor-applet-38-30.20240717git4bd03a2.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2024-b9b80eacd5 (gnome-shell-extension-system-monitor-applet-38-30.20240717git4bd03a2.fc39) has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.