I am unable to reproduce this. I just installed `celluloid`, ran `systemctl --user reload dbus-broker` and the service file was correctly loaded and I could launch the application.

The flatpak service-file location needs to be included in `XDG_DATA_DIRS` before dbus-broker is started. This means, you must reboot/relogin after installing flatpak itself (this could be avoided if flatpak used configuration files rather than environment variables, though). The directory does not have to exist, though. It is picked up on a configuration-reload, even if it did not exist before.

I am unsure what issue you ran into. There is a similar report on flatpak-upstream [1], which has not been investigated by the flatpak developers, though.

Lastly, your `Steps to Reproduce` say that you rebooted between the flatpak-install and attempting to launch it, and it is really confusing me. Can you double check for me that you listed those correctly?

[1] https://github.com/flatpak/flatpak/issues/3342

That is listed correctly. The only thing that alleviates the problem is a relogin. In fact, if the system is in a working state (after relogin), it becomes broken again after reboot. In which case, it is fixed by relogin.

Right. Thank you for verifying!

This is quite confusing, though. Somehow, your system seems to be unable to pickup service directories on boot, but requires a restart. `dbus-broker` does not differ in behavior between a restart or reload, so either this is a bug in dbus-broker, or another system is misbehaving.
I read through the reload-logic again and this should all be working fine. I also tested it locally. So my suspicion is that something else is off.

Now, given that you stated this is Silverblue, this might be related to environment-variable setup. I could imagine something like flatpak generating the `XDG_DATA_DIRS` configuration file at each boot in Silverblue, and thus it might be generated *AFTER* dbus-broker is started in the user-session. Hence, dbus-broker does not pick up the flatpak data-dir until you restart it (then systemd will re-evaluate the environment-setup and pass the updated set to dbus-broker). A configuration-reload would not help since environment-variables do not work like that.

This is obviously just a wild guess, but maybe someone of the flatpak+Silverblue developers can comment on that? And maybe flatpak can switch to providing a custom dbus-configuration rather than relying on an environment-update? This would be much less fragile in an early-boot scenario.

Sadly, I am not very involved in the Silverblue initiative, so I am a bit uncertain how exactly it behaves. Can you tell me whether this file exists for you:

    `/usr/lib/systemd/user-environment-generators/60-flatpak`

I think this is the file that sets up flatpak environments for other services.

I had that suspicion as well, the `systemctl --user show-environment` output I gave has all the same values for XDG BEFORE relogin (not working) and after relogin (working). The env generation script is also in the systemd directory.

(In reply to somethingsome2000+redhat from comment #4)
> I had that suspicion as well, the `systemctl --user show-environment` output
> I gave has all the same values for XDG BEFORE relogin (not working) and
> after relogin (working). The env generation script is also in the systemd
> directory.

I would assume the user environment being updated before you can query it. It is just that it is only picked up by a service after it is being restarted (as you cannot propagate environment changes into running processes).

I will try to catch some Silverblue engineers and ask for details. But can you query the environment of a running dbus-broker instance and see whether the variable is correctly set? You would have to check `ps auxf` for the right process-id and then run `cat /proc/<id>/environ`. You need to make sure to find the PID of the dbus-broker **user** instance. I would be interested whether this environment lacks the XDG updates or not. This would at least narrow down where the issue is.

I tracked down the PID using `systemctl --user status dbus-broker` and took a look at its environ. Indeed it looks like it's being run before systemd generates the proper environment. The XDG variables are not there. I thought the generator should run before other units. There must be something wrong with my system.

HOME=/var/home/moymoy
LANG=en_GB.UTF-8
LOGNAME=moymoy
PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin
SHELL=/usr/bin/fish
USER=moymoy
XDG_RUNTIME_DIR=/run/user/1000
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
NOTIFY_SOCKET=/run/user/1000/systemd/notify
MANAGERPID=1040
LISTEN_PID=1712
LISTEN_FDS=1
LISTEN_FDNAMES=dbus.socket
INVOCATION_ID=b9f59d7c100b4c619b7ab30eacef68a0
JOURNAL_STREAM=8:96436

For anyone with the same problem, I've worked around the issue with a systemd unit override conf

[Service]
Environment="XDG_DATA_DIRS=..."

(In reply to Chester Moy from comment #6)
> I tracked down the PID using `systemctl --user status dbus-broker` and took
> a look at its environ. Indeed it looks like it's being run before systemd
> generates the proper environment. The XDG variables are not there. I thought
> the generator should run before other units. There must be something wrong
> with my system.
> 
> HOME=/var/home/moymoy
> LANG=en_GB.UTF-8
> LOGNAME=moymoy
> PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin
> SHELL=/usr/bin/fish
> USER=moymoy
> XDG_RUNTIME_DIR=/run/user/1000
> DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
> NOTIFY_SOCKET=/run/user/1000/systemd/notify
> MANAGERPID=1040
> LISTEN_PID=1712
> LISTEN_FDS=1
> LISTEN_FDNAMES=dbus.socket
> INVOCATION_ID=b9f59d7c100b4c619b7ab30eacef68a0
> JOURNAL_STREAM=8:96436

Thanks for verifying.

I just verified: systemd definitely runs environment-generators before normal generators, and all that before starting any unit. So I can only imagine that a flatpak startup script writes that file. Or the path is somehow mounted late. I don't know, sorry.

Also, I will gladly help you track this down, but I don't see how this is in any way caused by dbus-broker, so I might not be the right person to debug this. So feel free to reassign to Flatpak/Silverblue developers, or put them on CC.

This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

It looks like I can reproduce that on Fedora 38 (Kinoite).

See: https://github.com/flathub/org.cockpit_project.CockpitClient/issues/29
See: https://github.com/flatpak/flatpak/issues/3342