FS#20399 - [xfce4-sensors-plugin] loses config

Attached to Project: Arch Linux
Opened by Vitaliy Berdinskikh (UR6LAD) - Saturday, 07 August 2010, 10:10 GMT
Last edited by Andreas Radke (AndyRTR) - Saturday, 29 January 2011, 12:27 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture i686
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
xfce4-sensors-plugin loses the config after reboot.

Additional info:
* package version(s)
1.0.0-2
* config and/or log files etc.
=== start of .config/xfce4/panel/panels.xml ===
<panels>
<panel>
...
<items>
<item name="xfce4-menu" id="12797834031"/>
...
<item name="xfce4-sensors-plugin" id="12811259970"/>
...
</items>
...
==== end of .config/xfce4/panel/panels.xml ====
The .config/xfce4/panel/xfce4-sensors-plugin-12811259970.rc is attached.


Steps to reproduce:
I config xfce4-sensors-plugin to use the "Core0 Temp" and "CPU FAN Speed" sensors.

If I reboot or shurdown my computer then plugin doesn't have any sensors.

If I config xfce4-sensors-plugin then logout then login (without reboot or shutdown) plugin works fine.

   xfce4-sensors-plugin-12811259... (0.6 KiB)
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Saturday, 29 January 2011, 12:27 GMT
Reason for closing:  Upstream
Comment by Andreas Radke (AndyRTR) - Saturday, 07 August 2010, 14:07 GMT
please check permissions of the conf file and its folder.
Comment by Vitaliy Berdinskikh (UR6LAD) - Monday, 09 August 2010, 19:40 GMT
$ ls .config/xfce4/panel/ -ld
drwx------ 2 *** users 1048 Авг 9 22:34 .config/xfce4/panel/

$ ls .config/xfce4/panel/xfce4-sensors-plugin-12811259970.rc -ld
-rw-r--r-- 1 *** users 663 Авг 9 22:34 .config/xfce4/panel/xfce4-sensors-plugin-12811259970.rc

I think xfce4-sensors-plugin loses a config because sources change their order. I have 4 source: acpitz-0, k8temp-c3, atk0110-0, ACPI. But in the previous session their order was atk0110-0, acpitz-0, k8temp-c3, ACPI. And when I login this evening the plugin loses a config again.
Comment by Andreas Radke (AndyRTR) - Tuesday, 10 August 2010, 05:23 GMT
I've never seen such trouble. Please ask on the xfce goodies list or file an upstream issue. It may be related to your certain configuration.
Comment by Andreas Radke (AndyRTR) - Saturday, 30 October 2010, 21:12 GMT
state?
Comment by Vitaliy Berdinskikh (UR6LAD) - Monday, 01 November 2010, 09:27 GMT
I added and configured the sensor applet last Saturday.
It seems it works now.
Comment by Vitaliy Berdinskikh (UR6LAD) - Tuesday, 02 November 2010, 06:10 GMT
Not work.
Comment by Andreas Radke (AndyRTR) - Tuesday, 02 November 2010, 14:44 GMT
If you don't contact the upstream developer it won't get fixed. Please ask in #xfce or its mailing lists and then if necessary file a bug.
Comment by Vitaliy Berdinskikh (UR6LAD) - Monday, 08 November 2010, 20:22 GMT
http://bugzilla.xfce.org/show_bug.cgi?id=6734 Sensors plugin randomly forgets its settings
Comment by Heiko Baums (cyberpatrol) - Wednesday, 10 November 2010, 19:12 GMT
I, too, thought that this was an upstream bug. That's why I reported it only upstream. But upstream closed it as invalid and refers to downstream.

This is upstream's comment about that:

"OK, thx for the detailed diff. In fact, this behaviour was intended because I
rather assumed to have new chips with other or new features (i.e. names)
because of other module drivers or new hardware. And in this case you rather
would not want to reuse the previous settings. For this purpose, the concept of
chip numbers was introduced.

By specifying the order in which modules load, you will be able to bypass this
problem, i.e. first load acpi and then lm-sensors-whatever module.

I will therefore close this bug as invalid at first; feel free to reopen it if
you have any strong arguments why I should neglect the order in which chips are
found.

Please also report to archlinux and indicate the workaround with the order in
which modules load, thanks."
Comment by Andreas Radke (AndyRTR) - Wednesday, 10 November 2010, 19:31 GMT
So you can workaround it yourself?
Comment by Vitaliy Berdinskikh (UR6LAD) - Wednesday, 10 November 2010, 20:14 GMT
%(

I look at my rc.conf:
DAEMONS=(syslog-ng !acpid network netfs hal @fam @crond @alsa @atd @sensors @sensord @gpm...)

hal starts acpid before sensors will start.
Comment by Heiko Baums (cyberpatrol) - Wednesday, 10 November 2010, 20:42 GMT
No, I can't, because I don't have an @ in my DAEMONS array. And I don't think that the problem is the order in which the daemons are loaded but the modules.
And there is no index parameter in the modules k8temp and it87 which are affected modules in my case. So I can't set the load order in /etc/modprobe.d/modprobe.conf.
Comment by Andreas Radke (AndyRTR) - Wednesday, 10 November 2010, 20:45 GMT
Afaik you can set the module order in the modules array in rc.conf that is loaded before the rest.
Comment by Heiko Baums (cyberpatrol) - Wednesday, 10 November 2010, 21:13 GMT
I can be wrong, but this is not possible. If I recall correctly I had such an issue with alsa modules earlier. Setting the load order was only possible by setting the module's parameters index in /etc/modprobe.d/modprobe.conf. Kernel modules are loaded pretty randomly regardless of the order in which they are set in the MODULES array.

But I reopened the upstream bug and explained this problem.
Comment by Heiko Baums (cyberpatrol) - Wednesday, 10 November 2010, 21:47 GMT
I had another look at the modules and /etc/conf.d/lm_sensors.

This is the content of this file besides some comments:

HWMON_MODULES="k8temp it87"
MODULE_0=k8temp
MODULE_1=it87

If this has an effect on the order in which these modules are loaded then they should always be loaded in a fixed order. In this case the order in which the modules are loaded can't be the reason for this bug.
Comment by Andreas Radke (AndyRTR) - Saturday, 29 January 2011, 12:27 GMT
this is definitely not a packaging bug so the discussion should only happen in the upstream report. closing this one.

Loading...