FS#30455 - [dbus-core] 1.6.0-5 breaks nm-applet

Attached to Project: Arch Linux
Opened by Martin F. Schumann (mfs) - Wednesday, 27 June 2012, 08:48 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 27 June 2012, 17:01 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Ionut Biru (wonder)
Dave Reisner (falconindy)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
I am using nm-applet in an Xfce environment to manage my network connections. After upgrading dbus-core to 1.6.0-5, nm-applet stopped to show up in my panel after boot. Nevertheless, the processes NetworkManager, nm-applet and dbus are running, and NetworkManager establishes a network connection. Btw, I am using systemd to start the daemons.

When I then start nm-applet manually, it shows up in the panel, but tells me that connecting to NetworkManager failed. The reason seems to be that dbus rejects to send a message from nm-applet to NetworkManager, as you can see from the systemd journal snippet below.

A downgrade to dbus-core 1.6.0-4 solved the issue.

Additional info:
* package versions:
network-manager-applet 0.9.4.1-1
networkmanager 0.9.4.0-6
networkmanager-openvpn 0.9.4.0-1
dbus 1.6.0-1
dbus-core 1.6.0-5
dbus-glib 0.100-1
lib32-dbus-core 1.6.0-1

* from the systemd journal:
Jun 27 10:21:47 mfs dbus-daemon[391]: dbus[391]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.29" (uid=1000 pid=822 comm="nm-applet ") interface="org.freedesktop.NetworkManager.Settings.Connection" member="GetSettings" error name="(unset)" requested_reply="0" destination="org.freedesktop.NetworkManager" (uid=0 pid=385 comm="/usr/sbin/NetworkManager --no-daemon ")
Jun 27 10:21:47 mfs dbus[391]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.29" (uid=1000 pid=822 comm="nm-applet ") interface="org.freedesktop.NetworkManager.Settings.Connection" member="GetSettings" error name="(unset)" requested_reply="0" destination="org.freedesktop.NetworkManager" (uid=0 pid=385 comm="/usr/sbin/NetworkManager --no-daemon ")
This task depends upon

Closed by  Dave Reisner (falconindy)
Wednesday, 27 June 2012, 17:01 GMT
Reason for closing:  Not a bug
Additional comments about closing:  user config error
Comment by Martin F. Schumann (mfs) - Wednesday, 27 June 2012, 11:36 GMT
Downgrading to dbus-core 1.6.0-4 (with following restart of the dbus service) only temporarily resolved the problem. After a suspend/resume cycle the problem was there again and did not vanish after a reboot.
So I downgraded one step further to dbus(-core) 1.4.20-1. From then, the problem has not occured again, neither after reboots or suspend/resumes. So this could possibly be an upstream instead of a packaging issue?
Comment by Martin F. Schumann (mfs) - Wednesday, 27 June 2012, 15:17 GMT
I've investigated the problem a bit further. It seems that D-Bus from version 1.6 on forbids nm-applet to communicate with NetworkManager. When I add some rules to the D-Bus default context for NetworkManager (see attached patch for /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf), the communication is fine again.
Some of the added rules are already part of the at_console="true" policy. So it seems that D-Bus from version 1.6 on does not consider nm-applet as at_console="true" anymore, which leads to the erronous behavior.
   add-default-rules.patch (1 KiB)
Comment by Dave Reisner (falconindy) - Wednesday, 27 June 2012, 15:50 GMT
Seems to me like this is a problem somewhere in the gnome stack because of our half-way integration with systemd (this problem doesn't occur with sysvinit). dbus 1.6 changed some of the semantics for determining at_console with systemd (logind) and we're not fully subscribing to it yet.
Comment by Martin F. Schumann (mfs) - Wednesday, 27 June 2012, 16:52 GMT
Thanks for the hint! I've now got it working with the default dbus config. The problem was I had not added 'session optional pam_systemd.so' to my /etc/pam.d files (as described in https://wiki.archlinux.org/index.php/Systemd#User_sessions). After adding this line to /etc/pam.d/tty and /etc/pam.d/lightdm the problem is solved.
Comment by Dave Reisner (falconindy) - Wednesday, 27 June 2012, 17:00 GMT
Ah, neat! Closing this up, then.

Loading...