chiark / gitweb /
bus-proxy: make StartServiceByName synchronous
authorDavid Herrmann <dh.herrmann@gmail.com>
Fri, 31 Jul 2015 11:25:04 +0000 (13:25 +0200)
committerSven Eden <yamakuzure@gmx.net>
Tue, 14 Mar 2017 09:07:22 +0000 (10:07 +0100)
The StartServiceByName() call was provided by dbus-daemon to activate a
service without sending a message. On receiption, dbus-daemon schedules
an activation request (different modes are supported) and sends back the
reply once activation is done.

With kdbus, we marked StartServiceByName() as deprecated. There is no
real reason to start services explicitly. Instead, applications should
just *use* the service and rely on it being activated implicitly.
However, we provide compatibility with dbus-daemon and implement
StartServiceByName() on the proxy via a call to
org.freedesktop.DBus.Peer.Ping() on the destination. This will activate
the peer implicitly as part of the no-op Ping() method call (regardless
whether the peer actually implements that call).

Now, the problem is, StartServiceByName() was synchronous on dbus-daemon
but isn't on bus-proxy. Hence, on return, there is no guarantee that
ListNames includes the activated name. As this is required by some
applications, we need to make this synchronous.

This patch makes the proxy track the Ping() method call and send the
reply of StartServiceByName() only once Ping() returned. We do not look
at possible errors of Ping(), as there is no strict requirement for the
peer to implement org.freedesktop.DBus.Peer. Furthermore, any interesting
error should have already been caught by sd_bus_send() before.

Note:
        This race was triggered by gdbus. The gdbus-proxy implementation
        relies on a name to be available after StartServiceByName()
        returns. This is highly fragile and should be dropped by gdbus.
        Even if the call is synchronous, there is no reason whatsoever to
        assume the service did not exit-on-idle before ListNames()
        returns.
        However, this race is much less likely than the startup race, so
        we try to be compatible to dbus-daemon now.


No differences found