Activation of multiple services provided by the same executable

Darren Garvey darren.garvey at
Thu Apr 4 04:23:51 PDT 2013

On 28 March 2013 10:54, Simon McVittie <simon.mcvittie at>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/
dbus-send --session --type=method_call --print-reply --dest=$1 /

$ cat Acme.Tool.service
[D-BUS Service]

$ cat Acme.AltTool.service
[D-BUS Service]
Exec=/usr/bin/ Acme.Tool

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.

>From bus/activation.c:

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
> handle_servicehelper_exit_error.
> 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]
>     Name=...AccountManager
>     Exec=/usr/libexec/mission-control-5
>     # ...MissionControl5.service
>     [D-BUS Service]
>     Name=...MissionControl5
>     ActivateInstead=...AccountManager
>     # ...ChannelDispatcher.service
>     [D-BUS Service]
>     Name=...ChannelDispatcher
>     ActivateInstead=...AccountManager

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 <>.
> 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...
URL: <>

More information about the dbus mailing list