D-Bus activated apps don't know about xdg-apps

[hadess]

Originally in:
https://bugzilla.gnome.org/show_bug.cgi?id=765716

1. Create and install mpv in xdg-app:
   https://github.com/hadess/hadess-xdg-app
2. Launch "nautilus" on the command-line
3. Right-click on a video file, select "Open with other application", and verify that mpv is in the list of available applications
4. Kill nautilus
5. Launch nautilus via gnome-shell
6. Repeat 3. -> mpv isn't in the list

[hadess]

The problem is that XDG_DATA_DIRS in the D-Bus activated app isn't correct. You can verify that if you have an "open terminal" type launched in nautilus.

[hadess]

We could fix this with a big hammer and export this in gnome-session directly.

[alexlarsson]

Ahh, i see.

Yeah, the problem is how xdg-app gets to install something into XDG_DATA_DIRS. I fixed this with the fedora packaging by adding gdm support for /usr/share/gdm/env.d/xdg-app.env which gets run before the dbus daemon

However, maybe you are using e.g. a jhbuild xdg-app, which does not set this up?

[hadess]

Nope, I'm using the distro version of xdg-app.

$ rpm -q xdg-app
xdg-app-0.5.2-1.fc24.x86_64
$ rpm -V xdg-app
$

[hadess]

It's possible that I misinterpreted this, and it's indeed a nautilus bug.

[alexlarsson]

Did you re-log-in after installing xdg-app?

[alexlarsson]

And, is XDG_DATA_DIRS in cat /proc/session-bus-pid/environ with the ~/.local/share/xdg-app/exports/share dir?

[hadess]

Did you re-log-in after installing xdg-app?

Yes

And, is XDG_DATA_DIRS in cat /proc/session-bus-pid/environ with the ~/.local/share/xdg-app/exports/share dir?

$ ps aux | grep dbus-daemon
dbus       701  0.3  0.0  60296  6128 ?        Ssl  Apr25  14:25 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
gdm       1530  0.0  0.0  58720  4520 ?        Ssl  Apr25   0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
gdm       1715  0.0  0.0  58404  3700 ?        Sl   Apr25   0:00 /bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
hadess    1961  0.0  0.0  60252  6100 ?        Ssl  Apr25   0:30 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
hadess    2021  0.0  0.0  58788  4668 ?        Sl   Apr25   0:04 /bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
hadess   28993  0.0  0.0 117188   900 pts/0    S+   13:48   0:00 grep --color=auto dbus-daemon
$ grep XDG_DATA /proc/1961/environ
$ cat /proc/1961/environ
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/busDISPLAY=:0HOME=/home/hadessLANG=en_GB.UTF-8LOGNAME=hadessPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/binSHELL=/bin/bashUSER=hadessXAUTHORITY=/run/user/1000/gdm/XauthorityXDG_RUNTIME_DIR=/run/user/1000MANAGERPID=1913LISTEN_PID=1961LISTEN_FDS=1LISTEN_FDNAMES=dbus.socket

Looks like it isn't. But is in a gnome-shell launched gnome-terminal:

$ echo $XDG_DATA_DIRS 
/home/hadess/.local/share/xdg-app/exports/share/:/var/xdg-app/exports/share/:/usr/local/share/:/usr/share/

But is in gnome-shell's environment:

$ ps aux | grep gnome-shell
gdm       1553  0.0  1.1 1751932 181848 tty1   Sl+  Apr25   3:47 /usr/bin/gnome-shell
hadess    2072  0.0  0.2 943528 36224 ?        Sl   Apr25   0:01 /usr/libexec/gnome-shell-calendar-server
hadess   26754  3.8  1.0 1806936 165396 tty2   Sl+  13:10   1:31 /usr/bin/gnome-shell
hadess   29073  0.0  0.0 117188   940 pts/0    S+   13:50   0:00 grep --color=auto gnome-shell
$ cat /proc/26754/environ
LC_PAPER=en_GB.utf8XDG_VTNR=2XDG_SESSION_ID=2LC_MONETARY=en_GB.utf8HOSTNAME=classicSHELL=/bin/bashHISTSIZE=1000LC_NUMERIC=en_GB.utf8QTDIR=/usr/lib64/qt-3.3QTINC=/usr/lib64/qt-3.3/includeUSER=hadessUSERNAME=hadessDESKTOP_SESSION=gnomePATH=/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/hadess/binMAIL=/var/spool/mail/hadessPWD=/home/hadessXDG_SESSION_TYPE=x11LANG=en_GB.UTF-8GDM_LANG=en_GB.UTF-8MODULEPATH=/etc/scl/modulefiles:/usr/share/Modules/modulefiles:/etc/modulefiles:/usr/share/modulefilesLC_MEASUREMENT=en_GB.utf8LOADEDMODULES=GDMSESSION=gnomeHISTCONTROL=ignoredupsSSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpassSHLVL=1HOME=/home/hadessXDG_SEAT=seat0XDG_SESSION_DESKTOP=gnomeLOGNAME=hadessQTLIB=/usr/lib64/qt-3.3/libXDG_DATA_DIRS=/home/hadess/.local/share/xdg-app/exports/share/:/var/xdg-app/exports/share/:/usr/local/share/:/usr/share/DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/busMODULESHOME=/usr/share/ModulesLESSOPEN=||/usr/bin/lesspipe.sh %sWINDOWPATH=2DISPLAY=:0XDG_RUNTIME_DIR=/run/user/1000XDG_CURRENT_DESKTOP=GNOMELC_TIME=en_GB.utf8XAUTHORITY=/run/user/1000/gdm/XauthorityBASH_FUNC_module()=() {  eval `/usr/bin/modulecmd bash $*`
}BASH_FUNC_scl()=() {  local CMD=$1;
 if [ "$CMD" = "load" -o "$CMD" = "unload" ]; then
 eval "module $@";
 else
 /usr/bin/scl "$@";
 fi
}QT_IM_MODULE=ibusXMODIFIERS=@im=ibusGNOME_DESKTOP_SESSION_ID=this-is-deprecatedXDG_MENU_PREFIX=gnome-QT_QPA_PLATFORMTHEME=qgnomeplatformSESSION_MANAGER=local/unix:@/tmp/.ICE-unix/26678,unix/unix:/tmp/.ICE-unix/26678SSH_AUTH_SOCK=/run/user/1000/keyring/sshDESKTOP_AUTOSTART_ID=10b1630fde89a94414146184180826207100000266780000GIO_LAUNCHED_DESKTOP_FILE=/usr/share/applications/org.gnome.Shell.desktopGIO_LAUNCHED_DESKTOP_FILE_PID=2

[alexlarsson]

The gdm env.d file should be parsed pretty damn early, so I don't understand why it is not in your dbus-daemon environment. Very strange.

[gcampax]

Fedora 24 defaults to the user bus, so dbus is activated by systemd, not by gdm, and it never sees the env.d snippets.
gdm needs to be patched to upload all the environment to the bus, not just DISPLAY/XAUTHORITY.
Or better yet, upload all the environment to systemd, which also fixes user services.

(gnome-terminal is also dbus activated, but it asks the launcher for the environment explicitly, hence it does not suffer from this bug)

[alexlarsson]

Yeah, the user services need to have the XDG_DATA_DIR too

[alexlarsson]

@halfline: Who can look into this?

[halfline]

man, how many times today do i have to shake my fist at environment variables? maybe pam_systemd should be doing the equivalent of "systemctl --user import-environment" at pam_open_session time. it's a little weird that per-session variables (like XDG_SESSION_ID etc) would get set in processes that aren't running in a specific session, but I guess it's no more weird than DISPLAY which we already have and need. @poettering might have an opinion on this bug.

Doing that change won't fix this issue though, since we load env.d after pam_open_session. we could move where env.d is processed to earlier, of course.

I think the easiest change would be to put dbus-update-activation-environment --all --systemd in /usr/bin/gnome-session (which is shell script wrapper we already have because environment variables are fist worthy).

[gcampax]

For the record, systemctl import-environment at some point was in Xsession scripts. But we stopped running Xsession scripts and stuff broke.

In any case, and for the specific case of xdg-app, you can make a drop-in file of the form
[Service]
Environment=XDG_DATA_DIRS=%h/.local/share/xdg-app/exports/share/:/var/xdg-app/exports/share/:/usr/local/share/:/usr/share/
in user@.service.d

and forget about the import-environment stuff.

[alexlarsson]

@gcampax That sounds awesome. Also fixes things that don't use gdm, but uses user sessions.

[alexlarsson]

@gcampax Unfortunately it seems %h expanded to /root when i did this...

[alexlarsson]

@poettering I created a /usr/lib/systemd/system/user@.service.d/xdg-app.conf file with this:

[Service]
Environment=XDG_DATA_DIRS=%h/.local/share/xdg-app/exports/share/:/var/xdg-app/exports/share/:/usr/local/share/:/usr/share/

And when i logged in as "alex" the session bus daemon got:

XDG_DATA_DIRS=/root/.local/share/xdg-app/exports/share/:/var/xdg-app/exports/share/:/usr/local/share/:/usr/share/

Is it meant to do that? Should not %h expand to /home/alex ?

[alexlarsson]

Its pretty weird. %u expands to "root" also, even though the main service file has "User=%i" and %i expands correctly (to 1000). I even added "User=%i" to my conf file in case there was some ordering issue, but it did not help.

[smcv]

For the record, systemctl import-environment at some point was in Xsession scripts.

We do the not-requiring-systemd equivalent in Debian too, but with a few obviously-session-specific variables filtered out, and only if you have the dbus-x11 package installed (basically standing in for "give me traditional Xsession processing, please" in the hope that one day it doesn't need to be mandatory): https://anonscm.debian.org/cgit/pkg-utopia/dbus.git/tree/debian/95dbus_update-activation-env

Please prefer to use dbus-update-activation-environment rather than systemctl - it makes sure non-systemd and systemd activation both get the variables, and recent dbus-daemon also forwards these variables to systemd even if you don't use it with --systemd.

[alexlarsson]

@smcv we need the env vars set even in wayland, so I don't get why it should be a x11 dependency?

[smcv]

In Debian, the Xsession.d glue is in dbus-x11 because I had hoped we can do something better in the glorious Wayland future (more sockets in $XDG_RUNTIME_DIR and fewer magic environment variables, ideally; but failing that, some sort of env.d arrangement), and to make it clear that it isn't the "legacy-free" code path. See also https://bugzilla.gnome.org/show_bug.cgi?id=736660.

I agree that xdg-app's current use of adjusting the environment is something that non-X11 sessions would need too. Is there a reason why you don't symlink the "exported" files into ${XDG_DATA_HOME:-~/.local/share}, which would make the environment-manipulation unnecessary?

[alexlarsson]

@smcv I don't want to modify a user-owned directory like the users ~/.local/share. For instance, when apps are uninstalled we remove desktop files from them. But ~/.local/share is where user-customized options like "open with" extra mimetypes etc are stored.

Same goes for the system xdg-app dir (/var/lib/xdg-app/exports/share), i don't want installing xdg-apps to modify /usr/share/ because it has data from other sources.

[halfline]

i pushed a workaround here: https://bugzilla.gnome.org/show_bug.cgi?id=766176 so you can probably close this out.

[hadess]

Sure.