Bug 71571 - failure when trying to connect to system message bugs (PolyciKit1, UDisks2)
Summary: failure when trying to connect to system message bugs (PolyciKit1, UDisks2)
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Havoc Pennington
QA Contact:
Depends on:
Reported: 2013-11-13 11:34 UTC by Elmar Stellnberger
Modified: 2013-11-18 12:23 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

/var/log/messages excerpt (199.27 KB, text/plain)
2013-11-13 11:40 UTC, Elmar Stellnberger
/var/log/messages without Apparmor (205.57 KB, text/plain)
2013-11-13 13:46 UTC, Elmar Stellnberger
full backtrace trying to start upowerd (4.29 KB, text/plain)
2013-11-13 14:51 UTC, Elmar Stellnberger
/var/log/messages with dbus-1.7.8 (214.34 KB, text/plain)
2013-11-13 19:08 UTC, Elmar Stellnberger
dbus-configure.spec.part (647 bytes, text/plain)
2013-11-15 09:52 UTC, Elmar Stellnberger

Description Elmar Stellnberger 2013-11-13 11:34:18 UTC
version: 1.7.4
  The whole system lags on startup of KDE for a longtime (see: messages). Whenever a file open/close dialogue is required the connection to udsiksd fails and you have to wait for long (Bug 71567).
Comment 1 Elmar Stellnberger 2013-11-13 11:40:05 UTC
Created attachment 89134 [details]
/var/log/messages excerpt
Comment 2 Simon McVittie 2013-11-13 12:30:54 UTC
(In reply to comment #0)
> version: 1.7.4

If you're going to use development snapshots of D-Bus, please keep up with the current version (currently 1.7.8); or use the stable branch instead (currently 1.6.x), which is strongly recommended for stable Linux distributions.

What distribution is this? (From the log, looks like SUSE or a variant?) Have you reported a bug to the distribution? For system-integration issues, initially reporting bugs to the distribution is often more effective than taking them upstream straight away.

> 2013-11-13T11:06:29.273346+00:00 linux-4wml kernel: [   33.948658] type=1400 audit(1384340789.012:31): apparmor="STATUS" operation="profile_load" name="/usr/share/gitweb/gitweb.cgi" pid=724 comm="apparmor_parser"

Have you tried without AppArmor? LSMs alter the system's behaviour in unpredictable ways.

> 2013-11-13T11:06:50.157353+00:00 linux-4wml upowerd[2021]: (upowerd:2021): UPower-ERROR **: failed to get pokit authority: Error initializing authority: Could not connect: No such file or directory
> 2013-11-13T11:06:50.160254+00:00 linux-4wml systemd[1]: upower.service: main process exited, code=killed, status=5/TRAP

A backtrace from this SIGTRAP would probably be enlightening.

> 2013-11-13T11:06:50.618915+00:00 linux-4wml polkitd[2036]: Lost the name org.freedesktop.PolicyKit1 - exiting

There's the PolicyKit failure. Please investigate why it is not able to own its own name - I suspect there might be a broken AppArmor policy in effect.
Comment 3 Elmar Stellnberger 2013-11-13 13:46:23 UTC
Created attachment 89141 [details]
/var/log/messages without Apparmor
Comment 4 Elmar Stellnberger 2013-11-13 13:50:09 UTC
openSUSE. They initially had a fix for it but then came a regression... Now they have not done anything about it for about a month (https://bugzilla.novell.com/show_bug.cgi?id=843166).
Comment 5 Elmar Stellnberger 2013-11-13 13:53:10 UTC
backtrace from this SIGTRAP would probably be enlightening: How can I try to launch it manually with gdb?
Comment 6 Elmar Stellnberger 2013-11-13 14:51:17 UTC
Created attachment 89148 [details]
full backtrace trying to start upowerd
Comment 7 Elmar Stellnberger 2013-11-13 19:08:20 UTC
Created attachment 89159 [details]
/var/log/messages with dbus-1.7.8

 ... and that is the way messages looks like with dbus-1.7.8: udisksd and upowerd wait for a policykit authority while PolicyKit simply says: "Lost the name org.freedesktop.PolicyKit1". I would believe a dbus-error or perhaps even an error of how PolicyKit uses dbus. What do you think?
Comment 8 Elmar Stellnberger 2013-11-13 19:11:30 UTC
Please investigate why it is not able to own its own name: How shall I do that? It obviously does not seem to be an Apparmor error. I have been testing without it.
Comment 9 Elmar Stellnberger 2013-11-14 10:25:24 UTC
Having analyzed this issue with Chengwei we got the following results:
If you try to start the PolicyKit1 daemon in debug mode then it says:

> /usr/lib/polkit-1/polkitd
Successfully changed to user polkitd
Error getting system bus: Could not connect: No such file or directory
** (polkitd:9271): WARNING **: Error getting system bus: Could not connect: No such file or directory
09:44:35.766: Loading rules from directory /etc/polkit-1/rules.d
09:44:35.767: Loading rules from directory /usr/share/polkit-1/rules.d
09:44:35.777: Finished loading, compiling and executing 3 rules
Entering main event loop
09:44:35.780: Lost the name org.freedesktop.PolicyKit1 - exiting
Shutting down
Exiting with code 0

 So the problem is in deed that it can not connect at all rather than just not being able to own its own name. However if you add the following line to all service files for dbus daemons of systemd (at least udisks2.service, upower.service and polkit.service) then the desktop environment will be operable again:
Comment 10 Elmar Stellnberger 2013-11-14 10:29:49 UTC
Would it be possible to compile a default socket address to listen on into DBUS so that we do not need to set this environment variable all the time? It think that would prevent a lot of issues also with helper programs like su that do not care about DBUS. If we can do that with ~/.Xauthority then we can do it with the DBUS system bus socket as well; at least I would believe.
Comment 11 Simon McVittie 2013-11-14 13:20:04 UTC
(In reply to comment #10)
> Would it be possible to compile a default socket address to listen on into
> DBUS so that we do not need to set this environment variable all the time?

It does have a default socket address: ${localstatedir}/run/dbus/system_bus_socket (normally /var/run/dbus/system_bus_socket in distribution packages). dbus.socket directs systemd to listen on that socket on dbus-daemon's behalf, and libdbus hard-codes "unix:path=" + that socket as the default address to connect to.

On modern Linux, /var/run should normally be a symlink or bind-mount or something to /run. Is that the case on your system?

What path appears in your dbus.socket systemd unit? (On my Debian system it's /lib/systemd/system/dbus.socket and contains ListenStream=/var/run/dbus/system_bus_socket.)

What path is hard-coded into your libdbus? ("strings ${libdir}/libdbus-1.so.3 | grep system_bus_socket" with an appropriate value for ${libdir} - on my Debian system it finds "unix:path=/var/run/dbus/system_bus_socket".)

In your distribution's build logs, in the summary at the end of configure.ac, what are the "System bus socket:" and "System bus address:"?

What configuration (configure command line) does your distribution use for dbus, and what patches do they apply, if any?
Comment 12 Elmar Stellnberger 2013-11-15 09:51:12 UTC
* No /var/run and /run are two totally different directories on my system.
* Sorry, no dbus.socket unit on my system; at least not below /lib/systemd/ or /etc/systemd/. Even a grep -R system_bus_socket * does not yield any such result.
* strings ./BUILD/dbus-1.7.8/dbus/.libs/libdbus-1.so.3 | grep system_bus_socket
OOps, that promises to become a little bit tricky.
*  egrep "System bus (socket|address):" ./BUILD/dbus-1.7.8/configure.ac
        System bus socket:        ${DBUS_SYSTEM_SOCKET}
        System bus address:       ${DBUS_SYSTEM_BUS_DEFAULT_ADDRESS}
* configure has something like
  --with-init-scripts=suse, --enable-systemd, --with-system-socket=/run/dbus/system_bus_socket (that would be correct), --with-systemdsystemunitdir=%{_unitdir} and some others (see for the attachement)
Comment 13 Elmar Stellnberger 2013-11-15 09:52:11 UTC
Created attachment 89256 [details]
Comment 14 Elmar Stellnberger 2013-11-16 11:25:22 UTC
Actually the bug was not in the core dbus libs; it was libgio which still had an old reference to /var/run instead of /run.
Comment 15 Simon McVittie 2013-11-18 12:23:13 UTC
Thanks for confirming that. I think your distribution should ensure that /var/run and /run are synonyms (like Debian did), but that's not D-Bus' problem.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.