(not sure about the right package)

I first noticed that when I connect by ssh, evince is very slow to
start. A "strace -f -ttt evince" shows a 15-second timeout followed
by a 10-second timeout, thus a 25-second delay, before the window
appears.

596523 1661956157.508741 execve("/usr/bin/evince", ["evince"], 0x7ffd33032d40 /* 146 vars */) = 0
[...]
596525 1661956158.116493 write(7, "\1\0\0\0\0\0\0\0", 8) = 8
596525 1661956158.116552 poll([{fd=6, events=POLLIN}, {fd=7, events=POLLIN}], 2, -1) = 1 ([{fd=7, revents=POLLIN}])
596525 1661956158.116614 read(7, "\1\0\0\0\0\0\0\0", 16) = 8
596525 1661956158.116670 poll([{fd=6, events=POLLIN}, {fd=7, events=POLLIN}], 2, -1 <unfinished ...>
596527 1661956158.607152 <... futex resumed>) = -1 ETIMEDOUT (Connection timed out)
596527 1661956158.607298 futex(0x564acebbcb20, FUTEX_WAIT_PRIVATE, 0, {tv_sec=14, tv_nsec=999998717}) = -1 ETIMEDOUT (Connection timed out)
596527 1661956173.607633 madvise(0x7f8ad8d72000, 8368128, MADV_DONTNEED) = 0
596527 1661956173.608448 exit(0)        = ?
596527 1661956173.608612 +++ exited with 0 +++
596523 1661956183.139691 <... poll resumed>) = 0 (Timeout)
596523 1661956183.139905 write(8, "\1\0\0\0\0\0\0\0", 8) = 8

A comment at
https://unix.stackexchange.com/questions/676410/evince-is-slow-to-open
based on information from https://bbs.archlinux.org/viewtopic.php?id=224787
(ssh is actually not involved at these URLs) says to run

  dbus-update-activation-environment --systemd \
    DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY

and it initially worked. But when I retried after killing all my
processes, I could see that this does not always solve the issue.
Worse, in my latest try, this command hanged. Perhaps there's
more to do...

According to https://bbs.archlinux.org/viewtopic.php?id=224787
various GNOME applications are affected, so I tried with nautilus
(which I had never used) as it is mentioned there, and I could
also noticed this 25-second delay before the window appears.

I'm not sure this is dbus-user-session, but I'll leave it there for now.

Please describe your exact scenario in more detail. For instance, are you
already logged in as the same user on a graphical console, or on a tty,
or in some other way? If yes, what desktop environment, display manager,
etc. are in use? Or are you assembling your own graphical environment from
individual components such as startx?

If you're expecting graphical applications to work "when I connect by
ssh", then presumably you're doing *something* that you're not saying,
either X11-over-ssh forwarding or a separate X11 session or a separate
Wayland session - otherwise these applications would have nowhere to
display their windows.

It might help to try to reproduce a minimal version of the same problem
in a virtual machine, perhaps starting from one of the Debian Live images.

This might help, or it might make things worse, depending where you run
it from and under what circumstances. I cannot know without more detail
of what scenario you are trying to fix.

In a Debian X11 environment, /etc/X11/Xsession.d/20dbus_xdg-runtime is
meant to do something similar for you, so if you are in an X11 environment
where that's not working, either something has gone wrong somewhere or
your X11 environment is not participating in Debian's system-integration
mechanisms.

    smcv

I can reproduce the problem when killing all my processes with
"kill -TERM -1", relogging via ssh, and starting evince.

Note: I can see that the following processes are created just after
evince is started (but still waiting for its window):
xdg-desktop-portal, xdg-document-portal, xdg-permission-store.

X11 forwarding. I do not use Wayland at all.

Do you mean something like the following?

https://linuxhint.com/install_debian10_virtualbox/

But /etc/X11/Xsession.d/20dbus_xdg-runtime isn't run via ssh, AFAIK.

Control: retitle -1 under ssh X11 forwarding, apps like nautilus that use xdg-desktop-portal start with 25s delay
Control: affects -1 + nautilus evince xdg-desktop-portal xdg-desktop-portal-gtk

Thank you, that is the crucial piece of missing context that I needed.

Yes, X11 forwarding is an example of an X11 environment that doesn't
participate in Debian's X11 integration. There has never been a particularly
coherent design for how X11 forwarding should fit into the D-Bus session
bus, or into systemd user sessions.

- boot a text-mode session (I used debian-live-11.4.0-amd64-standard.iso)
- sudo apt update
- sudo apt install openssh-server
- sudo systemctl enable --now ssh
- enable a ssh login (ssh-import-id is a useful way to do this quickly)
- sudo apt install nautilus
- (xdg-desktop-portal-gtk is pulled in as a dependency, this is significant)

and from another machine, in a ssh -X session:

- echo $DISPLAY
- nautilus

Expected result: nautilus starts quickly.

Actual result: it takes a while.

Looking at the systemd journal, I think the problem here is the interaction
between xdg-desktop-portal, its desktop-specific implementation (in this
case xdg-desktop-portal-gtk), and X11 forwarding:
...

Immediately after that failure, there is a 25 second gap in the message
timestamps, and then nautilus starts doing other setup:

Part of the root cause here is that xdg-desktop-portal-gtk is a systemd
user-service that cannot work without either an X11 or Wayland display
(its purpose is to show prompts when a sandboxed application wants to
do something that needs your permission); but during X11 forwarding,
no component is responsible for telling systemd --user where user-services
can find your X11 display, so xdg-desktop-portal-gtk fails to start.

Because X11 forwarding isn't part of the integrated system involving
x11-common, there's no good component to be responsible for that.
A ssh login session probably should *not* be doing this automatically,
because in your specific case (X11 forwarding with no local GUI),
it would be beneficial to tell systemd --user about your DISPLAY, but
in a more typical desktop use-case (local Wayland or X11), it would
be harmful to do that (because it would make parts of the overall GUI
unexpectedly pop up on the forwarded X11 display instead of locally,
until the forwarded display disconnects, at which point those parts of
the GUI would just not work at all).

Another problem here is that when xdg-desktop-portal-gtk fails and exits
unsuccessfully, that information is getting lost somewhere in the chain
of communication between nautilus, xdg-desktop-portal, dbus-daemon and
systemd --user. The result is that instead of an error being reported
back immediately, there is no reply to a D-Bus method call, which makes
something (either nautilus or xdg-desktop-portal, I can't immediately
tell which) unable to continue until its D-Bus client library gives up and
times out the method call, for which the default timeout is 25 seconds.
I think this might be because systemd does not send the ActivationFailure
message if a transaction is queued but later fails
(https://github.com/systemd/systemd/issues/21520), and nobody has taught
dbus-daemon to do more detailed monitoring of systemd's state to be able
to observe when a unit that it asked for has failed.

Another part of the problem here is probably that something (nautilus or
xdg-desktop-portal or both, probably both) is doing something over D-Bus
that talks to xdg-desktop-portal-gtk, and blocking until that method call
has finished, rather than doing it asynchronously if possible.

    smcv

I would expect this to be done dynamically (not at login time),
because the user may have several active X11 displays at the
same time: for instance, I have a personal machine at home and
another one at my lab, and whether I'm at home or at my lab,
I may want to start applications either locally or remotely. The
selected display should be the one from which the user started
the application (i.e. where the application window will appear).

Some additional information: this bug also triggers for me without X11 forwarding.

I don't run a desktop environment or graphical login (login in text mode and then `startx` with fluxbox launched from .xinitrc); but I still have xdg-desktop-portal-gtk fail to launch with the log message 'cannot open display:'.

Note that this adds a long delay to the startup of both inkscape and firefox as well; and that removing the xdg-desktop-portal and xdg-desktop-portal-gtk packages allows these programs to start normally. Perhaps something is spuriously requiring xdg-desktop-portal; since my system seems to function fine without it.

Probably because /etc/X11/Xsession is not used, as you're using you're
own .xinitrc file. I suppose that there would be no such issue with
the system /etc/X11/xinit/xinitrc file, which does

. /etc/X11/Xsession

(fluxbox could be launched from a .xsession file in this case).

IMHO, there should be some file under /etc/X11/Xsession that should
set an environment variable saying that the GUI/dbus system is fully
operational. Perhaps 95dbus_update-activation-env?

Then a GTK application should not try to use a portal if this
environment variable is unset.