Launching a GDesktopAppInfo "blames" parent process for its output
To reproduce:
- Have a web browser or other URL handler that:
- spams stdout/stderr with unattributed messages, like Chrome/Chromium in https://github.com/flatpak/xdg-desktop-portal/issues/828
- is not
DBusActivatable=true
- Use it as the implementation of xdg-desktop-portal OpenURI()
- Open a URI via that API
Expected result:
- Messages logged to the Journal are tagged as coming from the web browser or other URL handler
- Users whose web browser, etc. is broken complain to the maintainers of the web browser
Actual result:
- Messages logged to the Journal are tagged as coming from the parent process, in this case xdg-desktop-portal
- Users whose web browser, etc. is broken complain to the maintainers of the unrelated parent process
I think g_app_info_launch_uris()
and its relatives should have logic to call something like sd_journal_stream_fd ("google-chrome.desktop", LOG_INFO, 0)
and pass that fd to the launched process, analogous to what dbus-daemon does (we might want to reimplement sd_journal_stream_fd()
to avoid a dependency, but it's quite self-contained and its license is compatible, so that wouldn't be hard). This should definitely happen if the launched process would otherwise have inherited a stdout or stderr fd from us for which g_log_writer_is_journald()
, and maybe it can also happen in other cases?
If we are in the non-posix_spawn
code path, because sd_journal_stream_fd
and dup2
are documented as being async-signal-safe, it would be safe to do this in the child_setup
.
If we are in the posix_spawn
code path, we would have to use posix_spawn_file_actions_adddup2()
.
This is vaguely related to !1596 (closed). If it had been possible to implement !1596 (closed) with transient services, then systemd would do this for us; but because !1596 (closed) is using transient scopes, I think it's still up to GLib to set up stdout/stderr.