How does dbus-daemon handle multiple services with same Name?

[Armin K.]

On 06/21/2015 08:42 PM, Lennart Poettering wrote:
> On Sun, 21.06.15 13:02, Armin K. (krejzi at email.com) wrote:
> 
>> Hi,
>>
>> While trying kdbus with systemd, I have ran across a problem.
>> Apparently it doesn't yet properly handle multiple D-Bus services
>> with same name.
>>
>> I'm interested in how does D-Bus daemon handle this? Which one
>> gets loaded and how it decides which one to load?
>>
>> An example:
>>
>> I have two services with Name=org.freedesktop.FileManager1
>>
>> One is GNOME's Nautilus, other is MATE's Caja File Manager.
>> Which one would get loaded and why?
> 
> Only one service can own a name at a time. If one already owns a name,
> and another one tries to take possession of it as well, then one of
> three things can happen:
> 
>       a) the request to own the name is queued, and dbus-daemon passes
>       it on automatically and atomically as soon as the old owner
>       voluntarily gives it up.
> 
>       b) the operation to request the name will simply fail (this mode
>       of operation you get by passing DBUS_NAME_FLAG_DO_NOT_QUEUE when
>       acquiring the name)
> 
>       c) the name will be taken away forcible from the old owner (only
>       if the new owner indicated DBUS_NAME_FLAG_REPLACE_EXISTING, and
>       the old one DBUS_NAME_FLAG_ALLOW_REPLACEMENT).
> 
> Either way, and no times there are two owners of a name at the same
> time, neither in kdbus, nor in dbus-daemon.
> 
> Lennart
> 

I'm asking specifically because current dbus-daemon seems to
kinda handle it, but kdbus will error out when it tries to
create a symlink for bus-proxyd. I was asked on systemd
bug tracker how dbus handles this, that's why I asked here.

-- 
Note: My last name is not Krejzi.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20150621/5153b1a5/attachment.sig>