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.
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.