Introduced by bug 12236
To be checked if a fix can be sorted out.
Otherwise IMO bug 12236 should be reverted before release of 1.8.0.
Please could you describe the steps to reproduce this a bit more clearly? That would help to confirm or deny what I think is happening.
I conjecture that this is caused by unrelated apps that are launched by Thunar being direct child processes of Thunar (launched via Exec= rather than via DBusActivatable). When the main process exits, `systemd --user` decides that the rest of the cgroup should be cleaned up, and terminates its child processes; but because those child processes are unrelated apps, that's more destructive than it ought to be.
You could test this theory by launching an app that does have DBusActivatable=true in its desktop file (in Debian these include Evince, GNOME Builder, devhelp and gedit) and an app that is not DBusActivatable (such as gvim); then killing Thunar. If my theory is correct, the DBusActivatable app will not be killed, but the non-DBusActivatable app will be killed.
If my theory is correct, then adding KillMode=process to the systemd service file's [Service] group (similar to what gnome-terminal-server does) would avoid this.
Thanks alot for that theory !
I tried with devhelp and gedit, both get killed on thunar kill, as any other application started from desktop. ( I just double-click on a simple default starter )
This did not begin very promising, however for the sake of completeness I took a try for KillMode=process.
And indeed, now desktop applications are not killed any more \o/ *yay*
That's not exactly following your reasoning, but nevertheless a pleasant surprise ;)
You think we should just commit KillMode=process as a fix .... or somehow change the way thunar starts it's child processes ?
As far as I can tell, thunar uses xfce_spawn_on_screen which itself uses g_spawn_async to launch child processes. I did not see anything related to DBusActivatable so far:
Ah, I should add some more info to reproduce the bug:
- The bug only happens if thunar was started in daemon mode ( e.g. automatically after boot )
- It does not matter if I kill thunar, abort it or use thunar -q, the result is the same
new: The bug is not only triggered by .desktop files. As well anthing else opened within thunar will be killed. ( E.g. I opened a libreoffice document )
Argh, I was to fast with beeing happy. I did not properly test before, I did not start thunar as daemon.
So KillMode=process seems to have no effect ;(
> somehow change the way thunar starts it's child processes ?
More modern GLib APIs like GAppInfo (in the GIO library, I think Nautilus uses it if you need sample code) are able to make use of alternative ways to start .desktop files (like DBusActivatable), although if the .desktop file only has Exec= then they will still have to fall back to the equivalent of what you're doing now.
> So KillMode=process seems to have no effect ;(
I'm surprised by that: this is how e.g. gnome-terminal-server can leave processes started like "devhelp & disown" running after the gnome-terminal itself has exited, and that works fine for me.
Please show me what the systemd Journal says?
> The bug is not only triggered by .desktop files. As well anthing else opened within thunar will be killed. ( E.g. I opened a libreoffice document )
Anything that starts a long-running child process of Thunar will be affected.
Haha, I was to fast with beeing sad as well ;)
So far I still did not test properly.
Now I reboot before testing changes, so that dbus starts a real fresh thunar daemon ( instead of doing so from console )
Like that KillMode=process realy does the trick !!
Regarding support for DBusActivatable=true I opened a fresh bug: Bug 14282
Thanks again for your support !
Simon McVittie referenced this bugreport in commit 11c0a06dd4bfe5cd38789cee2f31cd7008b3508f
Killing thunar as well kills all launched sub-processes (bug #14277)
Please don't put my name on a commit unless I actually sent you a patch.
DBusActivatable=true is meaningless (unsupported) in systemd .service files, and also meaningless in D-Bus .service files. It's only applicable to .desktop files, where it's described by the fd.o Desktop Entry specification:
You can only put DBusActivatable=true in a .desktop file if the executable that you're launching supports the D-Bus API described in that specification. GApplication/GtkApplication is frequently used to implement the DBusActivatable API in GTK/GNOME-derived apps, and would probably also be suitable for XFCE, if XFCE still uses GTK (it's a while since I used XFCE myself, so I've lost track).
> Please don't put my name on a commit unless I actually sent you a patch.
Sorry, thought it would be appropriate, since you proposed the fix. I should have asked before.
And I should double check on what I commit next time .. specially when I do so in the name of others. Sorry again !
Will remove DBusActivatable=true from the .service file.
Yes, XFCE continues to use gtk, devs are still busy with moving all apps to gtk3. Release 4.14 hopefully somewhat this year.
Thanks for the clarifications! I will take a look which XFCE apps could make use of DBusActivatable=true in their .desktop files.
Alexander Schwinn referenced this bugreport in commit 214f9b984900dd4c226450d4139b008c52afb5ea
Killing thunar as well kills all launched sub-processes (bug #14277) - Removed "DBusActivatable=true" which I added accidentally