App launched for a "desktop action" inherits gnome-shell's Journal connection
Affected version
3.35.91 (from source code inspection, not reproduced)
Bug summary
If an app implements Desktop Actions via Exec=
rather than DBusActivatable
, then shell_app_launch_action()
leaves it connected to Shell's stdout/stderr.
(For context: the GNOME maintainers in Debian received a bug report about GNOME Shell logging > 20G of org.gnome.Shell.desktop[3434]: [8045:8045:0315/020158.705821:ERROR:gles2_cmd_decoder.cc(4007)] ContextResult::kFatalFailure: Could not allocate offscreen buffer storage
, which appears to be a message that actually comes from Chromium, prompting me to investigate how Shell could have ended up being "blamed" for this message.)
Steps to reproduce
From source code inspection, so this is a guess:
-
Have an app that implements Desktop Actions but does not implement
DBusActivatable
, such as Steam:[Desktop Entry] Name=Steam ... Exec=/usr/games/steam %U ... [Desktop Action Store] Name=Store ... Exec=steam steam://store
-
It is not initially running
-
Run it via one of its Desktop Actions, such as Steam's
Store
What happened
From source code inspection: it will be launched via g_desktop_app_info_launch_action()
, which will end up running ["steam", "steam://store"]
as a subprocess. Its stdout and stderr will be a copy of Shell's, so Shell will be "blamed" for anything it logs.
This is because there is no equivalent of g_desktop_app_info_launch_uris_as_manager[_with_fds]()
for desktop actions.
What did you expect to happen
The child process gets launched with its own private sd_journal_stream_fd()
.
Possible implementations
Solving this nicely is probably going to need new API in GLib.
If there was a g_desktop_app_info_launch_action_as_manager_with_fds()
analogous to g_desktop_app_info_launch_uris_as_manager[_with_fds]()
then GNOME Shell could call it.
Or Shell could maybe use g_desktop_app_info_get_boolean()
to determine whether the app is DBusActivatable
, and have a fast-path where it will (call into GLib APIs to) perform D-Bus activation, and a slow-path where it runs some sort of helper subprocess that is responsible for rewriting stdout/stderr and running the app?
Or maybe on systemd --user
systems, the non-D-Bus Exec=
path should be implemented (either in Shell, or in GLib in general) by asking systemd to run the app as a transient service (which would naturally get its own Journal connection), like systemd-run
?