Aug 17 14:04:37 xeon dbus-daemon: Rejected send message, 1 matched rules; type="method_call", sender=":1.93" (uid=1000 pid=16053 comm="kded4) interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination="org.freedesktop.ConsoleKit" (uid=0 pid=20444 comm="/usr/sbin/console-kit-daemon)) Aug 17 14:04:37 xeon dbus-daemon: Rejected send message, 1 matched rules; type="method_call", sender=":1.93" (uid=1000 pid=16053 comm="kded4) interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination="org.freedesktop.ConsoleKit" (uid=0 pid=20444 comm="/usr/sbin/console-kit-daemon)) Reproducible: Always
Are your config files all up-to-date and were the respective daemons restarted to be aware of the config changes?
(In reply to comment #1) > Are your config files all up-to-date and were the respective daemons restarted > to be aware of the config changes? > Same over here, all configuration files are up to date, including the files from the packages below, after daemon/system restart same messages in logfile. sys-auth/consolekit-0.3.0-r1 sys-apps/dbus-1.3.0 sys-apps/hal-0.5.13-r2
Same problem here, seems most of the messages have something to do with kde4 apps or the startup of kde4. Rejected send message, 1 matched rules; type="method_call", sender=":1.57" (uid=0 pid=10420 comm="konqueror) interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination="org.freedesktop.Hal" (uid=0 pid=6044 comm="/usr/sbin/hald)) Rejected send message, 1 matched rules; type="method_call", sender=":1.61" (uid=0 pid=32718 comm="kdeinit4: kio_trash [kdeinit] trash local:/tmp/kso") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination="org.freedesktop.Hal" (uid=0 pid=6044 comm="/usr/sbin/hald)) Rejected send message, 1 matched rules; type="method_call", sender=":1.35" (uid=1000 pid=9960 comm="kdeinit4: kded4 [kdeinit]) interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination="org.freedesktop.ConsoleKit" (uid=0 pid=6047 comm="/usr/sbin/console-kit-daemon))
Here's some more Rejected send message, 1 matched rules; type="method_call", sender=":1.88" (uid=0 pid=22106 comm="/usr/bin/krusader) interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination="org.freedesktop.Hal" (uid=0 pid=6044 comm="/usr/sbin/hald))
Introspectable, like most Hal dbus, is limited to group plugdev (if you do not have policykit) or at_console (if you do). Presumably you are do not have policykit and are not in plugdev. You'll need to fix one of those conditions.
(In reply to comment #5) > Introspectable, like most Hal dbus, is limited to group plugdev (if you do not > have policykit) or at_console (if you do). Presumably you are do not have > policykit and are not in plugdev. You'll need to fix one of those conditions. > you're completely wrong i have policykit and i'm in plugdev group
If you have policykit, then plugdev is irrelevant. Do you have consolekit running? Does it list you as being active? (ck-list-sessions will tell you what sessions consolekit knows about).
(In reply to comment #7) > If you have policykit, then plugdev is irrelevant. Do you have consolekit > running? Does it list you as being active? (ck-list-sessions will tell you > what sessions consolekit knows about). > Yep i have it running and ck-list-sessions show my session
Could you attach /etc/dbus-1/system.d/hal.conf
Created attachment 204237 [details] hal.conf
Are you by any chance logged in as root? If so, could you try as another user to see if that fixes it? I'm guessing (although I don't know) that the user=root overrides the policykit policy for dbus.
(In reply to comment #11) > Are you by any chance logged in as root? If so, could you try as another user > to see if that fixes it? I'm guessing (although I don't know) that the > user=root overrides the policykit policy for dbus. > no =) alexxy@xeon ~/gentoo-x86 $ whoami alexxy alexxy@xeon ~/gentoo-x86 $ id uid=1000(alexxy) gid=1000(alexxy) groups=10(wheel),12(mail),18(audio),19(cdrom),27(video),35(games),80(cdrw),100(users),250(portage),1000(alexxy),1003(plugdev)
Well, at least some of the posts above are running as root: Rejected send message, 1 matched rules; type="method_call", sender=":1.88" (uid=0 pid=22106 comm="/usr/bin/krusader) I wouldn't be surprised to find out that would break. Anyway, next guess. Can you run polkit-auth and post the output?
Same here. The program I'm working on needs to acquire the global storage lock from HAL - but it's method calls are just rejected. Why does somebody invent this behaviour? It wasn't like this before! - no Policykit (it once broke one of my machines) - consolekit enabled - root - root is also explicitely in the plugdev group - Error-Message: =============================================================== dobbelherz ~ # ./projects/scsi/build/scsi "DBUS-Interface zu HAL erstellt!" "Globales Lock holen: " QDBusMessage(type=Error, service="", error name="org.freedesktop.DBus.Error.AccessDenied", error message="Rejected send message, 1 matched rules; type="method_call", sender=":1.17" (uid=0 pid=3323 comm="./projects/scsi/build/scsi ") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination="org.freedesktop.Hal" (uid=0 pid=2901 comm="/usr/sbin/hald --use-syslog --verbose=yes "))", signature="", contents=() ) Object::connect: No such slot QApplication::close() in /root/projects/scsi/devicetable.cpp:67 Object::connect: (receiver name: 'scsi') release Lock: QDBusMessage(type=Error, service="", error name="org.freedesktop.DBus.Error.AccessDenied", error message="Rejected send message, 1 matched rules; type="method_call", sender=":1.17" (uid=0 pid=3323 comm="./projects/scsi/build/scsi ") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination="org.freedesktop.Hal" (uid=0 pid=2901 comm="/usr/sbin/hald --use-syslog --verbose=yes "))", signature="", contents=() ) ================================================================ Would it help to just kick out the line(s) about denial in /etc/dbus-1/system.conf? Why was this denial set up in the first place?
Stefan: Since you're not using policykit, could you post your /etc/dbus-1/system.d/hal.conf ? The denial was added because without it, anyone on the box (local or remote, with any kind of privileges) can play with your hardware settings. It's horribly insecure. I'm trying to find a nice middle ground between the people on single-user boxes who just want it to work and the people on multi-user boxes who want it secure.
The same here I think. hald daemon couldn't start as of consolekit can't start p4c ~ # /etc/init.d/hald start * Starting ConsoleKit daemon ... [ !! ] * ERROR: cannot start hald as consolekit could not start I think that it may be connected with http://bugs.gentoo.org/show_bug.cgi?id=336138 but they say that consolekit runs perfect
Sorry, made a mistake. It's here was said that consolekit is running but not in that bug
My story was from another bug. Re-emerging dev-libs/dbus-glib solved problem but now I have another problems: GNOME Desktop starts too slow and gnome-panel and some other apps works wrong
Maxim: Why is consolekit failing to start? Can you check /var/log/messages and so on to try to find out? I suspect it's unrelated to this bug (and therefore should have a different bug).
(In reply to comment #19) > Maxim: Why is consolekit failing to start? Can you check /var/log/messages and > so on to try to find out? I suspect it's unrelated to this bug (and therefore > should have a different bug). > Daniel, thanks for reply. As I said above I solved my problem by re-emerging dev-libs/dbus-glib. You're right, that was a story from another bug. Can't reproduce it now so can't post some kind of error messages here. Now I have some problems with long GNOME Desktop launching, gnome-panel and firefox. Now doing emerge -eav system (needed to do it before: many apps need to be emerged twice cause of gcc segfaults so I want to see can it solve this problem). Then I plan to reemerge every glib-depended app and take a look does the problem disappear. I'll post results here. Anyway, thank you. Sorry for my bad English.
sys-apps/hal was removed from tree wrt #313389, closing as OBSOLETE
