kdbus doesn't properly handle dbus services providing a same interface

[elkrejzi]

Lets say I have two packages providing a same D-Bus interface, in my case it's: org.freedesktop.FileManager1.

Yes, I have two file managers installed (and at a time, even more than two).

At login, on a VT or through lightdm, I see a following error in journal:

Jun 21 11:54:23 krejzi systemd[413]: Failed to create /run/user/63/systemd/generator.late/dbus-org.freedesktop.FileManager1.service: File exists
Jun 21 11:54:23 krejzi systemd[415]: /usr/lib/systemd/user-generators/systemd-dbus1-generator failed with error code 1.

[zonque]

How's that supposed to work in classic D-Bus setups with the daemon in place? Which of the two is started, and how is that decided?

[elkrejzi]

Beats me. Maybe we should ask on the dbus mailing list.

[grawity]

As far as I can understand, it would be started manually by the desktop environment... At least that's the case for org.freedesktop.Notifications.

Though in that case maybe the DBus service file shouldn't be there at all. It can be pretty annoying when dunst or notify-osd shows up just because gnome-shell took a while to claim the name. Same for file managers I guess.

[poettering]

@grawity well, activation files are about activation. If you don't need activation, then you shouldn't place any activation files – and even then you can still grab any name you like that the policy allows you to have,

Hence, having 2 activation files for the same name really makes no sense, you certainly shouldn't activate 2 services, and certainly not 0 either in this case. Which means you activate one and ignore the other. I kinda hope that dbus-daemon is doing that, but hopefully also logs about this issue...

[smcv]

What dbus-daemon actually does is to pick one arbitrarily (I think it depends on readdir order) and ignore the other. If there isn't a warning message, I would be happy to review a patch adding one.

I have never seen a particularly good design for "activate the right one chosen from a set of implementations of a well-known name". If someone can suggest one, I'd be happy to review patches to the D-Bus spec, but at the moment I can't think of a better answer than "pick one at random (and please try to avoid the situation arising)".

This can only happen on the session bus, because for backwards compat, we do not insist that the filename of session services matches the Name. Best-practice is that it should match, like it must on the system bus.

Instances of this anti-pattern: https://lintian.debian.org/tags/dbus-session-service-wrong-name.html

[zonque]

I'm still confused how all that should behave in a deterministic way. @elkrejzi - which of the many file managers is started in your case, and is what happens expected to happen?

I think our safest approximation to dbus-daemon would be to simply bail-out with a warning from the generator in case the file already exists.

[elkrejzi]

I think it's as @grawity already pointed out. Currently, Caja is started by the desktop environment, so no need for auto start by D-Bus. And since it' started, I presume it would register itself as a FileManager on D-Bus, no matter if it previously was or wasn't register. As I said, I don't know D-Bus very well, but it seems that correct File Manager is being utilized (Caja) despite the warning in the original report.

[smcv]

I don't think D-Bus service activation is a suitable technology for implementation-agnostic names, like the o.fd.FileManager name that is shared between Nautilus, Caja and similar file managers, or the o.fd.Notifications name that is shared between notification-daemon, gnome-shell and similar notification providers, and so on.

GNOME Shell is not D-Bus-activatable under the o.fd.Notifications name; it is only started by the GNOME session. Similarly, if Nautilus is configured to provide desktop icons, it is auto-started by /etc/xdg/autostart, but it is not D-Bus-activatable under that name. If all the implementations behaved similarly, there'd be no problem.

Another possibility would be if GNOME, Mate etc. prepended /usr/share/gnome, /usr/share/mate etc. to XDG_DATA_DIRS, such that under (GNOME|Mate|...) the search path found (Nautilus|Caja|...)'s .service file in /usr/share/(gnome|mate|...)/org.freedesktop.FileManager.service and so on; that would be one way to make it at least deterministic. However, that interacts very poorly with the user bus, which needs to start a dbus-daemon (or a kdbus-enabled systemd) before the desktop environment has started.

I'm still confused how all that should behave in a deterministic way

It doesn't, and it can't. The only thing that dbus-daemon could do to make this deterministic would be to apply a different arbitrary choice, like "first filename in alphabetical order", instead of "(first|last) in readdir() order".

At the moment, iterating through the directories in $XDG_DATA_HOME:$XDG_DATA_DIRS is deterministic, but iterating within a directory is not.

[kaysievers]

Bus names and file names need to match with native kdbus. With dbus-1 they don't, but I don't think we can make work with dbus-1 compat. Closing.

[elkrejzi]

How about at least handling the non-zero exit status of the generator (return if symlink exists or overwrite it)?

[poettering]

@elkrejzi not sure i groke what you are suggesting?

I mean, the config is kinda broken when you have two files for the same activatable names, so it should generate an error.

[elkrejzi]

Given that D-Bus was handling it error-free (not that I say in the right way, but it never has thrown an error in such situation), it wouldn't be a smooth upgrade if something started throwing an error about something you never encountered before, especially when you log into your account on tty.

I agree that this needs to be fixed on the faulty service side, but until then at least make it less verbose - not getting in an user's way (no noise on tty), while letting the devs know they're doing it wrong.

[poettering]

@elkrejzi I very much disagree. dbus-daemon should rather be fixed to also warn about these errors.