[Pkg-utopia-maintainers] Bug#994865: Delayed start due to Pipewire not running

[Simon McVittie]

On Thu, 23 Sep 2021 at 15:36:17 +0200, Vincent Bernat wrote:
>  ❦ 23 September 2021 10:08 +01, Simon McVittie:
> > Are you sure this is triggered by upgrading xdg-desktop-portal, and not
> > by upgrading some related package - perhaps x-d-p-gtk or pipewire?
> 
> I don't have Pipewire installed (but it was installed at some point).

You do have the client library libpipewire-0.3-0, though, because
xdg-desktop-portal Depends on it - so an upgrade to that package might
have been what triggered this.

(Or, what you're seeing might be completely unrelated to Pipewire.)

> Unfortunately, it seems the problem only happens on boot.

Logout/login might be sufficient to reproduce this with less loss
of state.

What else is going on in the Journal at the time that the delay happens?
It would be ideal if you could do something like:

- log in
- wait a few seconds for everything to settle, to reduce irrelevant logging
- use xterm or some other unaffected mechanism to run
  `logger -t timestamp "before delayed start"`
- start an affected GTK app

I see from your initial bug report that you are using systemd as pid 1,
systemd --user, and dbus-user-session (i.e. dbus-daemon --session is
running as a systemd --user unit). Is that correct?

What desktop environment are you using? Or if you have made your own
desktop environment from individual components, what are the major
components like window manager and session manager (if any)?

It might be helpful to run the affected GTK app with G_MESSAGES_DEBUG=all
in the environment. This doesn't work for gnome-terminal because
gnome-terminal is weird, but gnome-terminal -vv is close enough.

> the delay happens only once.

This probably indicates that it's to do with some other component that
xdg-desktop-portal talks to, which doesn't start up properly or doesn't
reply to a method call the first time. On the second and subsequent
attempts, if the other component is already running, then x-d-p is more
likely to be able to communicate with it immediately, hence no delay.

> The delay is related to the
> fact that VTE terminals (like Gnome Terminal) are "GTK apps" and they
> synchronize with DBus to find an existing instance if any.

Most components that talk to xdg-desktop-portal only do so when they find
that they're running as a Flatpak app, or maybe some other sandboxed app
framework like Snap. Just to rule some things out: are you launching
Flatpak and/or Snap apps? Or if not, do you have environment variable
GTK_USE_PORTAL set?

One thing for which the GTK 3 implementation of GtkApplication *does*
use xdg-desktop-portal, even when not in a container, is: if it was
unable to communicate with gnome-session or XFCE's equivalent, it will
try to use xdg-desktop-portal's Inhibit proxy, to attach to an appropriate
desktop-specific mechanism for monitoring desktop session state if one is
available. It's possible that it's doing this more often than it really
needs to, or more synchronously than it really needs to.

    smcv