Providing several well-known names vs. activation

[Will Thompson]

On 16/05/11 09:52, Sascha Silbe wrote:
> So my questions are:
> 
> 1. Is my analysis of the code correct, i.e. does D-Bus currently have
>    no way of preventing race conditions during activation of processes
>    providing multiple bus names?
> 2. Is support for multiple bus names per pending activation planned?
>    (The code looked too complex for me to come up with a patch myself,
>    sorry).

To both, not as far as I know, except that systemd and Upstart-based
activation do a better job.

> 3. Is there a better way of addressing my use case (providing both
>    native and compatibility services) that works with the current
>    version of D-Bus?

A trick I've seen/used is:

    [D-Bus Service]
    Name=com.example.RealService
    Exec=/usr/lib/real-service

    [D-Bus Service]
    Name=uk.co.example.ForeignService
    Exec=/usr/lib/launch-real-service

where launch-real-service is something like:

    #!/usr/bin/python
    import dbus
    import sys

    dbus.StarterBus().start_service_by_name('com.example.RealService')

This relies on the bus not caring whether or not the actual process it
executed quits, as long as someone claimed the relevant name and holds
onto it. start_service_by_name() throws an exception if anything goes
wrong activating the real name, which makes this process exit uncleanly,
which alerts dbus-daemon that activating the foreign name failed.

I don't think your application needs to claim the two names in any
particular order to make this race-free (but could be wrong).

-- 
Will