The Gnome Panel "CPU Frequency Scaling Monitor" 2.30.0 is no longer able to select the CPU scheduler (e.g. performance vs. ondemand). Reproducible: Always Steps to Reproduce: 1. Add the CPU frequency scalling monitor (cpufreq-applet) to the panel. 2. Attempt to use it to switch from "performance" to "ondemand" governor. 3. Now no longer provides ability to do so. Actual Results: cpufreq-applet fails to offer ability to switch CPU governor. Expected Results: cpufreq-applet should allow qualified users to switch between governors. Applet still knows which scheduler is present, e.g. positioning the mouse over the panel icon will indicate either "performance" or "ondemand" as well as the CPU use. However the only way to change the setting is using scripts, e.g. echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor There would be an argument that the CPU scheduler type and frequencies (e.g. scaling_max_feq and scaling_min_freq) should not be limited to "root". This probably requires a udev ownership/permissions change (arguably anyone in the "root" group, or with wheel/admin privileges should be able to fiddle with the hardware settings). In this case the cpufreq applet needs to be a bit more sophisticated in that it needs to determine whether or not the user has rights (presumably via access() calls) to change the scheduler type and offers the user (via the gnome-panel-applet) the option to do so. My subjective impression is that this *used* to work in gnome-applets-2.26 or gnome-applets-2.28.
In my case it works fine: 1. I try to switch from ondemand to permormance 2. A dialog is opened asking me for root password to apply the change 3. It applies the change once I provided desired password Please note I have "policykit" USE flag enabled system wide
I can confirm that recompiling gnome with USE flag "policykit" solves the problem.
Ok, accepting the feedback and assuming it is valid, I've got gnome-applets built with policykit but "gnome-base/gnome" built with "-policykit". Anybody have any idea what program this is affecting that implements the desired behavior (e.g. asking/confirming permissions to change the governor)? I ask because I keep a log of all ebuilds and it is easy to tie a program modification (install) date to an ebuild date (thus deducing what package with what specific USE settings may have created a problem). Raises the question of, if the gnome policykit setting distributes down to affect the gnome-applets setting, *what* is the point of the gnome-applets policykit setting? (since the desired results appear to be usurped by the senior level partner).
I think you're looking at the problem wrong. It's probably a conflict with your applets being built to integrate with PolicyKit but your Gnome installation not supporting it. You probably need either BOTH to be built with PolicyKit support or neither.
policykit is the kind of use flag that doesn't work well when half-enabled. Please enable it on gnome-base/gnome, it will pull required dependencies for proper operation.
I've recompiled everything with policykit and this still does *not* fix the problem. If one looks at the source: gnome-applets-2.30.0/cpufreq/src/cpufreq-selector.c it does have POLKIT/!POLKIT capabilities. With POLKIT in effect it looks like there has to be some granting of permissions regarding: org.gnome.CPUFreqSelector; /org/gnome/cpufreq_selector/selector and org.gnome.CPUFreqSelector which doesn't appear to be explained anywhere. In the case of non-POLKIT I suspect the user has to be a member of a group that has permission to read/write the files involved (from the looks of cpufreq-popup.c in terms of what menus are displayed). It should be noted that POLKIT is really a waste of time for single-user workstations and should not be the default Gentoo release option (IMO). I've got 2-3 userid's I want to have complete control over the machine (typically the VT I am logged in as) and I want the rest of the users to have no privileges. This can be handled perfectly well with groups and doesn't require dragging in all of the DBUS overhead. The bug is not INVALID and not RESOLVED.
We will wait for http://bugs.gentoo.org/show_bug.cgi?id=334307#c7 since you seem to be the only one suffering this problem and, then, we need to try to ensure you have a "clean" system
I am reasonably convinced at this point that this problem is entirely due the fact that the cpufreq-applet may have been unable to communicate with dbus. This seems to be a result of the fact that no users (not even root) were present as members of the "messagebus" group in /etc/group. So it is not a policykit problem (indeed I'm now running gnome-applets and gnome-panel -policykit). The key insight was in realizing that "/usr/libexec/dbus-daemon-launch-helper" is SUID, owned by root:messagebus but DOES NOT have "other" execute permissions (i.e. mode 4710) as well as wondering about the gnome-power-manager errors [1]. I'm not sure when "messagebus" was added as a group but my initial gentoo installation was circa 2005 and my first dbus installation was in 2006 which may explain why the group doesn't have the proper added users. There should *clearly* be a message added to "dbus" and/or gnome-applets that users may need to check membership in this group if they expect dbus (and applets) to function properly. Gentoo may also want to add some code to "emerge --info" which greps for critical root/admin/messagebus/??? IDs in /etc/passwd & /etc/group so subtle permission errors are more easily caught (I think I've seen at least 3 Gentoo bugs involving this). [This bug can be considered "resolved" after the messagebus group concerns are addressed.] Also, it would be nice to know *where* the Devicekit-power package sources come from and where error reports can be filed. The error messages from this package are *really* not useful. It is also worth noting that the "ondemand" request will be ignored unless p4-clockmod.c is hacked in the kernel. One will however receive an error in kern.log: "ondemand governor failed, too long transition latency of HW, fallback to performance governor" so one can easily tell when one needs to hack at the ondemand governor. 1. e. g. "(gnome-power-manager:605): devkit-power-gobject-WARNING **: Error invoking GetAll() to get properties: Failed to execute program /usr/libexec/dbus-daemon-launch-helper: Success"
(In reply to comment #8) > I am reasonably convinced at this point that this problem is entirely due the > fact that the cpufreq-applet may have been unable to communicate with dbus. > > This seems to be a result of the fact that no users (not even root) were > present as members of the "messagebus" group in /etc/group. But it's normal, look at my /etc/group file: messagebus:x:441: And I promise you I have no problem at all on five different machines :-/ >So it is not a > policykit problem (indeed I'm now running gnome-applets and gnome-panel > -policykit). The key insight was in realizing that > "/usr/libexec/dbus-daemon-launch-helper" is SUID, owned by root:messagebus but > DOES NOT have "other" execute permissions (i.e. mode 4710) as well as wondering > about the gnome-power-manager errors [1]. It also looks normal, in my case I have: $ ls -l /usr/libexec/dbus-daemon-launch-helper -rws--x--- 1 root messagebus 141568 jun 8 02:08 /usr/libexec/dbus-daemon-launch-helper > > I'm not sure when "messagebus" was added as a group but my initial gentoo > installation was circa 2005 and my first dbus installation was in 2006 which > may explain why the group doesn't have the proper added users. There should > *clearly* be a message added to "dbus" and/or gnome-applets that users may need > to check membership in this group if they expect dbus (and applets) to function > properly. > That group is created by sys-apps/dbus, but there seem to be no need of adding you to that group, but I don't know why do you require it :-| I am running sys-apps/dbus-1.2.24 > > Also, it would be nice to know *where* the Devicekit-power package sources come > from and where error reports can be filed. The error messages from this > package are *really* not useful. If you are referring to send bug reports to upstream, you should look for upower since it replaces devicekit-power: http://upower.freedesktop.org/ http://lists.freedesktop.org/mailman/listinfo/devkit-devel > > It is also worth noting that the "ondemand" request will be ignored unless > p4-clockmod.c is hacked in the kernel. That is a different problem (probably a kernel one) but, if I don't misremember, one of the machines I maintain is a P4 one and I had to disable ondemand on it since it was buggy and caused some problems. I also saw some bug reports years ago in mandriva bugzilla and it could be disabled intentionally :-/ > One will however receive an error in > kern.log: "ondemand governor failed, too long transition latency of HW, > fallback to performance governor" so one can easily tell when one needs to hack > at the ondemand governor. > It enforces my idea about it being intentional, you should probably consult this with kernel guys (but it looks to me like an upstream issue than a gentoo one) > 1. e. g. "(gnome-power-manager:605): devkit-power-gobject-WARNING **: Error > invoking GetAll() to get properties: Failed to execute program > /usr/libexec/dbus-daemon-launch-helper: Success" > I would consult the following links: http://bugs.gentoo.org/show_bug.cgi?id=291273 http://bugs.gentoo.org/show_bug.cgi?id=281640 http://bugs.gentoo.org/show_bug.cgi?id=222551 As a side note, my dbus-glib is 0.86 (even having this version already, try to re-emerge it anyway and see if the problem still occurs)
