Activation of multiple services provided by the same executable

[Darren Garvey]

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:

----------8<----------
$ cat /usr/bin/ping-service.sh
#!/bin/bash
dbus-send --session --type=method_call --print-reply --dest=$1 /
org.freedesktop.DBus.Peer.Ping

$ cat Acme.Tool.service
[D-BUS Service]
Name=Acme.Tool
Exec=/usr/bin/acmetool
User=acme

$ cat Acme.AltTool.service
[D-BUS Service]
Name=Acme.AltTool
Exec=/usr/bin/ping-service.sh Acme.Tool
User=acme
---------->8----------

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
"daemonize".


> 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
explicit.

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

Cheers,

Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20130404/7969bcd3/attachment.html>