DBusActivatable launches app in root directory

[Gerald Nunn]

I'm the maintainer of a tiling terminal application called Terminix (https://github.com/gnunn1/terminix). By default, terminix has DBusActivatable=true in it's desktop launch configuration. However when this is enabled, Unity will launch Terminix with the CWD set to the root ('/') directory rather then the user's home. This doesn't happen for all users, but it is consistent in that if the user has the issue they always have the issue.

This causes issues for my users because Terminix uses it's CWD when first launched to determine what the shell's initial directory should be. You can see bug reports on this issue at the following links:

https://github.com/gnunn1/terminix/issues/285
https://github.com/gnunn1/terminix/issues/214
https://github.com/gnunn1/terminix/issues/216
https://github.com/gnunn1/terminix/issues/220

I can reproduce on Unity 16.04 in a VM, I can see that the while the CWD is set to the root directory, the PWD environment variable is set to the user's home directory as expected. For now I'm working around it by checking if the --gapplication-service parameter was passed, if so if the CWD!=PWD I set the CWD to PWD.

Another thing that works is changing DBusActivatable=false in the desktop file, however I'd prefer to avoid maintaining two desktop files.

I'd really like to understand why this happening and confirm if it's something I'm doing wrong on my side. This configuration works fine in other launchers like Gnome Shell, it's only Unity where I have the issue. I used the dbus-monitor to inspect messages when Unity launches Terminix and I'm not seeing an obvious problem.

[Gerald Nunn (gnunn)]

Looks like this is a general issue with Unity and DBusActivatable, I see baobab (the disk usage analyzer) which is also set to use DBusActivatable exhibits the same behavior in my VM:

gnunn@gnunn-VirtualBox:/usr/share/applications$ cat org.gnome.baobab.desktop
[Desktop Entry]
Name=Disk Usage Analyzer
Comment=Check folder sizes and available disk space
Keywords=storage;space;cleanup;
TryExec=baobab
Exec=baobab
Icon=baobab
Terminal=false
Type=Application
StartupNotify=true
MimeType=inode/directory;
Categories=GTK;GNOME;System;Filesystem;X-GNOME-Utilities;
NotShowIn=KDE;
X-GNOME-Bugzilla-Bugzilla=GNOME
X-GNOME-Bugzilla-Product=gnome-utils
X-GNOME-Bugzilla-Component=baobab
X-GNOME-Bugzilla-Version=3.18.1
DBusActivatable=true
X-Ubuntu-Gettext-Domain=baobab
gnunn@gnunn-VirtualBox:/usr/share/applications$ ps -ef | grep baobab
gnunn 14590 1097 0 22:40 ? 00:00:00 /usr/bin/baobab --gapplication-service
gnunn 14598 2126 0 22:40 pts/5 00:00:00 grep --color=auto baobab
gnunn@gnunn-VirtualBox:/usr/share/applications$ ls /proc/14590/cwd
bin boot cdrom core dev etc home initrd.img lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var vmlinuz
gnunn@gnunn-VirtualBox:/usr/share/applications$

[Marco Trevisan (Treviño) (3v1n0)]

Mh I think the issue is upstart and dbus-session related more than an unity issue.

In fact:
 $ ls /proc/$(pgrep -u $USER dbus-daemon | head -n1)/cwd -l
 lrwxrwxrwx 1 marco marco 0 mag 31 15:58 /proc/940/cwd -> /

Thus the process that has the role of launching these kind of apps, and it's the one responsible for setting the proper CWD.

Unfortunately, it seems that just calling chdir in /usr/share/upstart/sessions/dbus.conf is not enough.