dbus-daemon/dbus-broker not told to reload after installing new D-Bus services

[damianatorrpm]

Linux distribution and version

Fedora Silverblue 31

Flatpak version

1.6

Description of the problem

Installed dbus.service not found till reboot

Steps to reproduce

flatpak --user install org.jami.Jami
flatpak --user run org.jami.Jami

Run fails until reboot as above requires a ring dbus service which has been installed in exports but is not launched till reboot.
Does flatpak look in the xdg data sirs for dbus services and these are not updated?

[alexlarsson]

Flatpak isn't what needs to look into the dbus service dirs, instead it is the dbus daemon itself that should do this. In the fedora packages this is done by various config files:

• /usr/lib/systemd/user-environment-generators/60-flatpak
• /usr/share/gdm/env.d/flatpak.env
• /etc/profile.d/flatpak.sh

These all try to set the XDG_DATA_DIRS env var which dbus-daemon then uses to locate the service files.

I wonder why this is not working though. I mean, a reboot does find it it so it seems the env var is set on the second boot at least. Maybe something about how the service files are changed doesn't cause dbus to detect that a file has changed and it needs to re-read the directory.

My guess is that this is related to fedora using dbus-broker, maybe its service-file scanning cache system is different somehow.

[damianatorrpm]

So I tried this with fresh installs:

`XDG_DATA_DIRS=$HOME/.local/share/.flatpak/exports (or exports/share)
flatpak --user run org.jami.Jami` #fails

systemctl restart dbus-broker.service #kicks you out of user session 
flatpak --user run org.jami.Jami #works

will try now to do just systemctl reload dbus-broker.service

[damianatorrpm]

bus1/dbus-broker#219

[dvdhrm]

Every process has their own set of environment variables. If you change XDG_DATA_DIRS in your shell before running flatpak, it will NOT affect the already running dbus-broker. Even a reload does not change this, since the environment variable of dbus-broker is not affected by this.

dbus-broker works exactly the same way as dbus-daemon. If that is not the case, it is a bug and I will gladly fix it. However, I do not understand what this bug is about. Can somebody elaborate what exactly is not working?

[damianatorrpm]

Example 1)
What I see as the incorrect behavior of the dbus-broker is that XDG_DATA_DIRS=$XDG_DATA_DIRS:$SHINY_NEW_DIR /path/to/dbus_activatable_app_that_needs_shiny_new_dir_where_service_file_is_located
will fail to start the dbus_activable_app as it does not pick up $SHINE_NEW_DIR as a directory to look inside for service files

Example 2)
Is maybe a duplicate of bus1/dbus-broker#211

before running flatpak, it will NOT affect the already running dbus-broker. Even a reload does not change this, since the environment variable of dbus-broker is not affected by this.

And how to affect dbus-broker to look inside another directory for service files? (e.g if creating a new flatpak installation, currently this would require a reboot of the system, restarting dbus-broker ends your user session)

[dvdhrm]

@alexlarsson

I wonder why this is not working though.

Do you actually share a directory across flatpaks, or do you create a new one for each? If you do the latter, how is dbus supposed to update its environment? How is this supposed to work?

[damianatorrpm]

@dvdhrm

Do you actually share a directory across flatpaks, or do you create a new one for each?

The feature flatpak-installations does create a new one. man flatpak | grep installation

If you do the latter, how is dbus supposed to update its environment?

To me it seems currently only after reboot.

Is there some way to force dbus broker to look into different directory or something that could achieve that?

[dvdhrm]

The feature flatpak-installations does create a new one. man flatpak | grep installation

So when that feature was introduced into flatpak, how was this supposed to propagate into dbus-daemon?

[damianatorrpm]

So when that feature was introduced into flatpak, how was this supposed to propagate into dbus-daemon?

Maybe it was decided that rebooting is fine.
The point is that the pieces of the Linux OS should work together as good as possible.
Is there some way to force dbus broker to look into different directory or something that could achieve that?

[dvdhrm]

Is there some way to force dbus broker to look into different directory or something that could achieve that?

Surely! The dbus-daemon(1) man-page lists all the supported configuration options. It also documents the XDG_DATA_DIRS behavior.

One simple approach would be to place a drop-in configuration into the system.d directory with a new <servicedir> element in it. Either rely on automatic refresh, or use ReloadConfig() on the bus to reload the configuration.

Please note that environment-variables are not global state, neither do they have a standardized way to update them at runtime. They are built up when starting a session or service etc., but cannot be remotely updated at runtime.

[alexlarsson]

@dvdhrm Flatpak creates two fixed locations where the service files are put, /var/lib/flatpak/exports/share/dbus-1/services/ for system installed flatpak and ~/.local/share/flatpak/exports/share/dbus-1/services/ for per-user installed ones. There is no real way for flatpak the app to modify the dbus daemon to pick this up, instead it is up to each packager of flatpak to use whatever setup the distro has to add these directories to the XDG_DATA_DIRS env var before the dbus daemon is started.

What I think is weird in this report is that installing a flatpak, which created a service file in one of these dirs, didn't cause dbus-broker to find the new service. However, once rebooted it did find it. Assuming flatpak was installed at the time of the last boot, the XDG_DATA_DIRS env var should have been the same in both these runs, so why did it require a reboot to pick up the new service?

[dvdhrm]

What I think is weird in this report is that installing a flatpak, which created a service file in one of these dirs, didn't cause dbus-broker to find the new service. However, once rebooted it did find it. Assuming flatpak was installed at the time of the last boot, the XDG_DATA_DIRS env var should have been the same in both these runs, so why did it require a reboot to pick up the new service?

Right. This should just work as expected. And this definitely works with dynamically installed rpms etc. You just need to make sure to use systemctl reload or another trigger of ReloadConfig().

Does anyone have a reproducer for that?

[alexlarsson]

@

Right. This should just work as expected. And this definitely works with dynamically installed rpms etc. You just need to make sure to use systemctl reload or another trigger of ReloadConfig().

Do we really need to trigger these for session bus services?

[dvdhrm]

Do we really need to trigger these for session bus services?

If you do not trigger them, you have a race-condition. There is no guarantee the inotify-event will be handled before anyone starts interacting with the service.

Sure, in most cases you do not care, since this is probably user-triggered stuff. But as soon as someone installs something through scripts, you probably want this to be synchronous.

Lastly, not all situations use inotify-events. dbus-daemon has some obscure logic where and when to use inotify (and we tried to copy that behavior, but we might have gotten it wrong). In most cases, you are better off just triggering the reload.

[rmnvgr]

A user of my flatpak app stumbled upon this and after some investigation, I found the following (each tried on a new Fedora VM, installing fr.romainvigier.MetadataCleaner and running it with gapplication launch fr.romainvigier.MetadataCleaner):

• If it is the first flatpak installed on the system, and the session hasn't been restarted after installation, launching fails with error sending Activate message to application: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable.
• After restarting the session, launching it works as expected.
• Creating the ~/.local/share/flatpak/exports/share/dbus-1/services (for a user installation) or /var/lib/flatpak/exports/share/dbus-1/services (for a system installation) directories, restarting the session, installing the application and launching it without restarting the session works as expected.

So it seems that because the services directories do not exist when the session is started, when they are created when a flatpak is installed, DBus does not react to any changes in them.

[mcatanzaro]

Coming here from #4849...

I found #3145 where the issue is fixed in the case where the directory already exists.

So we have two remaining problems:

• Noticing new symlinks in service directories bus1/dbus-broker#211 is closed but should surely be reopened (and a similar bug report for dbus-daemon is still needed).
• Need to figure out how to make this work when the directory is newly created (seems restarting the message bus is unavoidable? but that's pretty unfortunate)

[smcv]

seems restarting the message bus is unavoidable?

Restarting the message bus is not something you can do (it would crash the whole desktop environment). Telling it to reload is OK.

The reason why dbus-daemon doesn't detect services in newly-created directories is that you can't put an inotify watch on a directory that doesn't exist yet. The situation for dbus-broker is probably very similar.

With hindsight, using inotify to watch for new services on an "if possible" basis was probably a mistake, and always requiring an explicit reload action (like systemd does) would probably have been better, but that ship has sailed.

[smcv]

use ReloadConfig() on the bus to reload the configuration

I would recommend this as the route to solve this issue, in preference to systemctl reload. That way, flatpak doesn't need to know or care whether the message bus is dbus-daemon, dbus-broker or something else, or whether the session is systemd-managed or not.

[swick]

A trigger with dbus-send --session --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ReloadConfig might be enough, no?

[chrisawi]

A trigger with dbus-send --session --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ReloadConfig might be enough, no?

I don't think the sandbox would allow that. Also, triggers are executed by the system helper for the system installation.