Activation of multiple services provided by the same executable

Simon McVittie simon.mcvittie at collabora.co.uk
Thu Mar 28 03:54:05 PDT 2013


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.

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

or even this:

    # real file ...AccountManager.service
    # symlink ...MissionControl5.service -> ...AccountManager.service
    # symlink ...ChannelDispatcher.service -> ...AccountManager.service
    [D-BUS Service]
    Name=...AccountManager
    Exec=/usr/libexec/mission-control-5
    OtherNames=...MissionControl;...ChannelDispatcher;

(System services have the constraint that the name x.y.z is described in
x.y.z.service, so that the setuid activation helper does not need to
perform a directory search; this is also best-practice, although not
required, for session services.)

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

    S


More information about the dbus mailing list