Bug#760142: systemd: Assertions from systemd-logind on powerpc during login, with continuing loop

[Simon McVittie]

On 01/09/14 22:55, Chris Tillman wrote:
> Sep 02 09:44:00 debian dbus[767]: [system] Failed to activate service
> 'org.freedesktop.Avahi': timed out
> Sep 02 09:44:01 debian dbus[767]: [system] Failed to activate service
> 'org.freedesktop.PolicyKit1': timed out
> Sep 02 09:44:25 debian dbus[767]: [system] Failed to activate service
> 'org.freedesktop.systemd1': timed out
(etc.)

I think this is the root cause:

Aug 31 09:08:48 debian systemd[1]: Starting D-Bus System Message Bus...
Aug 31 09:08:48 debian systemd[1]: Started D-Bus System Message Bus.
...
Aug 31 09:09:13 debian systemd[1]: Failed to register to bus: Did not
receive a reply. Possible causes include: the remote application did not
send a reply, the message bus security policy blocked the reply, the
reply timeout expired, or the network connection was broken.

(Note that that's exactly 25 seconds, the default timeout in libdbus and
possibly other D-Bus implementations.)

systemd is meant to connect to the system dbus-daemon shortly after
starting it, so that it can receive service activation requests from
dbus-daemon. In this case, this doesn't seem to have worked. The failing
call appears to be the initial call to Hello() from
manager_bus_async_register(). In practice manager_bus_async_register()
runs while the system is busy, so it should perhaps use an explicit
timeout value (or even DBUS_TIMEOUT_INFINITE, which is INT32_MAX)
instead of using -1 (which means "use the default", i.e. 25 seconds).

systemd >= 209 uses its own D-Bus implementation, sd-bus, instead of
libdbus, and in that implementation, it uses an infinite timeout for
Hello(). (Don't be confused by the different notation: in sd-bus, unlike
libdbus, a timeout of ((uint64) -1) is infinite, and a timeout of 0
means "use the default".)

    S