There must be some policy file which forbids systemsettings to contact console-kit-daemon via dbus. I'm using dbus-1.3.0 and consolekit-0.3.0-r1. Aug 10 23:59:38 PesaBook dbus-daemon: Rejected send message, 1 matched rules; type="method_call", sender=":1.64" (uid=1000 pid=12725 comm="/usr/bin/systemsettings) interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination="org.freedesktop.ConsoleKit" (uid=0 pid=1322 comm="/usr/sbin/console-kit-daemon)) Aug 10 23:59:38 PesaBook dbus-daemon: Rejected send message, 1 matched rules; type="method_call", sender=":1.64" (uid=1000 pid=12725 comm="/usr/bin/systemsettings) interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination="org.freedesktop.ConsoleKit" (uid=0 pid=1322 comm="/usr/sbin/console-kit-daemon))
There are two items that seem to have this error, kded4 and systemsettings. The Power Management applet within System Settings reports "There are some issues in your configuration. Please check the Capabilities page for more details." The Capabilities page shows that "ConsoleKit Runtime Support" is not active or cannot be contacted by PowerDevil. /etc/dbus-1/system.d/ConsoleKit.conf indeed does not have any references to org.freedesktop.DBus.Introspectable, but I'm not sure if that is supposed to matter.
Yeah, this really seems a bug of consolekit's dbus policy. Even root isn't allowed to introspect the service!
Adding <allow send_destination="org.freedesktop.ConsoleKit" send_interface="org.freedesktop.DBus.Introspectable"/> to the default policy fixes the issue for me.
Created attachment 202619 [details, diff] Fixes the issue with introspection This patch is already combined with consolekit-0.3.0-allow-setidle.patch, thus it should replace that one.
Seems fixed in sys-auth/consolekit-0.4.1
So the dependency should be changed to require said consolekit version.
(In reply to comment #5) > Seems fixed in sys-auth/consolekit-0.4.1 > I upgraded to 0.4.1 (AMD 64), logged out, restarted the daemon, but the issue persists.... thanks, Ian
Seeing the same issue here... I have a clean install of ~x86 with consolekit 0.4.1 installed. How can I go about debugging this?
I seem to be hit by this when using powerdevil. -> bug #296502 Consolekit-0.3.0-r2 seems to have a variant of the above patch, but the issue remains.
Could it be a policy issue ? Can somebody with this bug and kde 4 installed please try the following: As root, start up the "systemsettings" Go to the "Advanced" Tab. Under "PolicyKit Authorization" Try to modify org.freedesktop.consolekit.system.* to some nonrestrictive values. Does this change anything? (at least it resolved bug #296502)
(In reply to comment #10) > As root, start up the "systemsettings" > Go to the "Advanced" Tab. > Under "PolicyKit Authorization" > Try to modify > org.freedesktop.consolekit.system.* > to some nonrestrictive values. > > Does this change anything? > (at least it resolved bug #296502) I tried ... when selecting the Power Management module, I now get a large yellow triangle and the following text (more or less, had to retype as it was not selectable to copy): "The configuration module cannot be started, since there seems to be a problem with the PowerDevil Daemon. Read below for more details. PowerDevil seems not to be started. Either you have its service turned off, or there is a problem in D-Bus." All buttons except Help are greyed out. ps ax | grep "ower" produces no results. /home/ian $ rc-update show alsasound | boot apache2 | default bootmisc | boot checkfs | boot checkroot | boot clock | boot consolefont | boot cupsd | default hald | default hostname | boot keymaps | boot local | default nonetwork localmount | boot metalog | default modules | boot mysql | default net.eth0 | default net.lo | boot netmount | default ntp-client | default ntpd | default pure-ftpd | default rmnologin | boot urandom | boot vixie-cron | default Is this like the ALSA issues where there is some daemon that's meant to be running, that's not? thanks, Ian
> Is this like the ALSA issues where there is some daemon that's meant to be > running, that's not? Well, you don't have dbus running, right? In this case it is not supposed to work, I think. I also have the "consolekit" daemon running.
(In reply to comment #12) > > Is this like the ALSA issues where there is some daemon that's meant to be > > running, that's not? > > Well, you don't have dbus running, right? In this case it is not supposed to > work, I think. I also have the "consolekit" daemon running. > Mmm .. okay Ian expects portage to take care of that sort of thing.. :-) However on my other machine, which has the same problem, I do have both running: spider ian # rc-update show alsasound | boot bootmisc | boot checkfs | boot checkroot | boot clock | boot consolefont | boot consolekit | default cupsd | default dbus | default hald | default hostname | boot keymaps | boot local | default nonetwork localmount | boot modules | boot mysql | default net.eth0 | default net.lo | boot netmount | default rmnologin | boot syslog-ng | default urandom | boot vixie-cron | default I tried opening systemsettings as root as requested above, but got the same error screen as reported above. However I notice that root is not a member of plugdev on this box ... attempting to fix .... spider ian # groupmems -a root -g plugdev Segmentation fault whoops. not good. I ask about plugdev because it may be connected to the sound issues that I also have on both boxes. http://forums.gentoo.org/viewtopic-t-807983-start-0-postdays-0-postorder-asc-highlight-.html cheers, Ian
> I tried opening systemsettings as root as requested above, but got the same > error screen as reported above. However I notice that root is not a member of > plugdev on this box ... attempting to fix .... Root is not in the plugdev group here neither.
How about kde-4.4.4?
At comment 11 and 14: I suspect that you get things working if you have consolekit and dbus started. consolekit and dbus should be in the boot runlevel and hald should be in the default runlevel. Having done that you should look as user in a konsole window in KDE that consolkit knows about your session. the command is ck-list-sessions. Furthermore it might help to check /etc/PolicyKit/PolicyKit.conf, if your user is allowed to access anything. But that's just a guess. See Bug #295152
Please reopen if this still happens with recent kde.
