Activation of multiple services provided by the same executable
darren.garvey at gmail.com
Thu Apr 4 04:23:51 PDT 2013
On 28 March 2013 10:54, Simon McVittie <simon.mcvittie at collabora.co.uk>wrote:
> On 27/03/13 19:46, Darren Garvey wrote:
> > We have a situation where some of our processes expose themselves over
> > dbus with more than one well-known name.
> telepathy-mission-control does this too. It's directly activatable under
> the last name it acquires (AccountManager) and the .service file for its
> other name (MissionControl5) runs a helper utility which requests
> activation of AccountManager, waits for that name to exist, then exits.
> (It's util/wait-for-name.c in our source tree.) This only works because
> dbus-daemon does not currently require that the process that eventually
> takes the name is a descendant of the process that it executed.
We have similar tools that we can use which fix the problem we're seeing,
albeit in a rather inelegant way.
Why do you need to wait for the busname to appear in your helper utility?
Rather than using say a "ping" script? For example, something akin to this:
$ cat /usr/bin/ping-service.sh
dbus-send --session --type=method_call --print-reply --dest=$1 /
$ cat Acme.Tool.service
$ cat Acme.AltTool.service
My hope would be that dbus-daemon would see that the "Exec" in the alias
service file had exited with a zero return code and then wait for a
RequestName message for the expected bus name. This /appears/ to work after
some testing, but I'm not convinced.
1337 /* There are two major cases here; are we the system bus or the
> session? Here this
> 1338 * is distinguished by whether or not we use a setuid helper
> launcher. With the launch helper,
> 1339 * some process exit codes are meaningful, processed by
> 1340 *
> 1341 * In both cases though, just ignore when a process exits with
> status 0; it's possible for
> 1342 * a program to (misguidedly) "daemonize", and that appears to us
> as an exit. This closes a race
> 1343 * condition between this code and the child process claiming the
> bus name.
> 1344 */
> 1345 uses_servicehelper = bus_context_get_servicehelper
> (pending_activation->activation->context) != NULL;
I haven't fully followed through this code to be sure if we need to wait,
but the comment above implies otherwise. In this case, the ping script
would return with a 0 exit status which I guess would look like a
> This could be extended to cover an arbitrary number of "secondary names"
> (MissionControl5 here; potentially ChannelDispatcher in future) pointing
> to one "primary name" (AccountManager here).
> This is not a great solution, and D-Bus would be better off if we could
> write something like this (analogous to systemd's Alias):
> # ...AccountManager.service
> [D-BUS Service]
> # ...MissionControl5.service
> [D-BUS Service]
> # ...ChannelDispatcher.service
> [D-BUS Service]
I prefer this solution over the other (snipped from below). It's more
> If not, we might consider patching dbus to make it check the "Exec"
> > in a service file in a similar way to how it checks the service name,
> > to fix any raciness in this situation.
> This was added in commit 075945f6 (with a not-particularly-helpful
> changelog entry) and reverted in commit 171934b37, because this
> behaviour is not described in the spec and it was breaking conversion of
> some system services to systemd activation (which for some reason
> involved changing those services to Exec=/bin/false).
> See <https://bugs.freedesktop.org/show_bug.cgi?id=35750>.
> So, to merge this, I'd need a clear explanation of why it's OK (or
> possibly, how those services were wrong and how they could have been
> corrected), and a patch to the D-Bus Specification describing the new
> de-duplication semantics.
OK. Thanks for the history, very useful.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dbus