Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1018880: dbus-user-session: GNOME applications such as evince and nautilus start with a 25-second delay via ssh
358 views
Skip to first unread message
Vincent Lefevre
Sep 1, 2022, 6:40:05 AM9/1/22
to
Package: dbus-user-session
Version: 1.12.20-2
Severity: important
(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.
-- System Information:
Debian Release: 11.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-15-amd64 (SMP w/28 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dbus-user-session depends on:
ii dbus 1.12.20-2
ii libpam-systemd 247.3-7
ii systemd 247.3-7
Versions of packages dbus-user-session recommends:
ii systemd-sysv 247.3-7
dbus-user-session suggests no packages.
-- no debconf information
--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Version: 1.12.20-2
Severity: important
(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.
-- System Information:
Debian Release: 11.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-15-amd64 (SMP w/28 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dbus-user-session depends on:
ii dbus 1.12.20-2
ii libpam-systemd 247.3-7
ii systemd 247.3-7
Versions of packages dbus-user-session recommends:
ii systemd-sysv 247.3-7
dbus-user-session suggests no packages.
-- no debconf information
--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Simon McVittie
Sep 7, 2022, 4:30:05 AM9/7/22
to
On Thu, 01 Sep 2022 at 12:22:28 +0200, Vincent Lefevre wrote:
> (not sure about the right package)
I'm not sure this is dbus-user-session, but I'll leave it there for now.
> (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.
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.
> 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
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
Vincent Lefevre
Sep 7, 2022, 5:40:04 AM9/7/22
to
On 2022-09-07 09:19:26 +0100, Simon McVittie wrote:
> On Thu, 01 Sep 2022 at 12:22:28 +0200, Vincent Lefevre wrote:
> > 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.
>
> 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?
There is no graphical console: the machine is accessible only via ssh.
> On Thu, 01 Sep 2022 at 12:22:28 +0200, Vincent Lefevre wrote:
> > 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.
>
> 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?
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.
> 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.
https://linuxhint.com/install_debian10_virtualbox/
> > 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
>
> 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.
Simon McVittie
Sep 7, 2022, 7:00:03 AM9/7/22
to
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
On Wed, 07 Sep 2022 at 11:35:52 +0200, Vincent Lefevre wrote:
> On 2022-09-07 09:19:26 +0100, Simon McVittie wrote:
> > If you're expecting graphical applications to work "when I connect by
> > ssh", then presumably you're doing *something* that you're not saying
>
> X11 forwarding.
Thank you, that is the crucial piece of missing context that I needed.
> > 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.
>
> But /etc/X11/Xsession.d/20dbus_xdg-runtime isn't run via ssh, AFAIK.
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.
> > 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.
A minimal reproducer seems to be:
- 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:
> Sep 07 10:19:22 debian dbus-daemon[5956]: [session uid=1000 pid=5956] Activating via systemd: service name='org.freedesktop.portal.Desktop' unit='xdg-desktop-portal.service' requested by ':1.1' (uid=1000 pid=5954 comm="nautilus ")
> Sep 07 10:19:22 debian systemd[1201]: Starting Portal service...
...
> Sep 07 10:19:22 debian dbus-daemon[5956]: [session uid=1000 pid=5956] Activating via systemd: service name='org.freedesktop.impl.portal.desktop.gtk' unit='xdg-desktop-portal-gtk.service' requested by ':1.8' (uid=1000 pid=6015 comm="/usr/libexec/xdg-desktop-portal ")
> Sep 07 10:19:22 debian systemd[1201]: Starting Portal service (GTK+/GNOME implementation)...
> Sep 07 10:19:22 debian xdg-desktop-portal-gtk[6031]: Unable to init server: Could not connect: Connection refused
> Sep 07 10:19:22 debian xdg-desktop-por[6031]: cannot open display:
> Sep 07 10:19:22 debian systemd[1201]: xdg-desktop-portal-gtk.service: Main process exited, code=exited, status=1/FAILURE
> Sep 07 10:19:22 debian systemd[1201]: xdg-desktop-portal-gtk.service: Failed with result 'exit-code'.
> Sep 07 10:19:22 debian systemd[1201]: Failed to start Portal service (GTK+/GNOME implementation).
Immediately after that failure, there is a 25 second gap in the message
timestamps, and then nautilus starts doing other setup:
> Sep 07 10:19:47 debian dbus-daemon[5956]: [session uid=1000 pid=5956] Activating via systemd: service name='org.gtk.vfs.UDisks2VolumeMonitor' unit='gvfs-udisks2-volume-monitor.service' requested by ':1.1' (uid=1000 pid=5954 comm="nautilus ")
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
Control: affects -1 + nautilus evince xdg-desktop-portal xdg-desktop-portal-gtk
On Wed, 07 Sep 2022 at 11:35:52 +0200, Vincent Lefevre wrote:
> On 2022-09-07 09:19:26 +0100, Simon McVittie wrote:
> > If you're expecting graphical applications to work "when I connect by
> > ssh", then presumably you're doing *something* that you're not saying
>
Thank you, that is the crucial piece of missing context that I needed.
> > 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.
>
> But /etc/X11/Xsession.d/20dbus_xdg-runtime isn't run via ssh, AFAIK.
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.
> > 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.
- 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:
> Sep 07 10:19:22 debian dbus-daemon[5956]: [session uid=1000 pid=5956] Activating via systemd: service name='org.freedesktop.portal.Desktop' unit='xdg-desktop-portal.service' requested by ':1.1' (uid=1000 pid=5954 comm="nautilus ")
> Sep 07 10:19:22 debian systemd[1201]: Starting Portal service...
...
> Sep 07 10:19:22 debian dbus-daemon[5956]: [session uid=1000 pid=5956] Activating via systemd: service name='org.freedesktop.impl.portal.desktop.gtk' unit='xdg-desktop-portal-gtk.service' requested by ':1.8' (uid=1000 pid=6015 comm="/usr/libexec/xdg-desktop-portal ")
> Sep 07 10:19:22 debian systemd[1201]: Starting Portal service (GTK+/GNOME implementation)...
> Sep 07 10:19:22 debian xdg-desktop-portal-gtk[6031]: Unable to init server: Could not connect: Connection refused
> Sep 07 10:19:22 debian xdg-desktop-por[6031]: cannot open display:
> Sep 07 10:19:22 debian systemd[1201]: xdg-desktop-portal-gtk.service: Main process exited, code=exited, status=1/FAILURE
> Sep 07 10:19:22 debian systemd[1201]: xdg-desktop-portal-gtk.service: Failed with result 'exit-code'.
> Sep 07 10:19:22 debian systemd[1201]: Failed to start Portal service (GTK+/GNOME implementation).
Immediately after that failure, there is a 25 second gap in the message
timestamps, and then nautilus starts doing other setup:
> Sep 07 10:19:47 debian dbus-daemon[5956]: [session uid=1000 pid=5956] Activating via systemd: service name='org.gtk.vfs.UDisks2VolumeMonitor' unit='gvfs-udisks2-volume-monitor.service' requested by ':1.1' (uid=1000 pid=5954 comm="nautilus ")
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
Vincent Lefevre
Sep 9, 2022, 3:00:03 PM9/9/22
to
On 2022-09-07 11:50:53 +0100, Simon McVittie wrote:
> 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).
I would expect this to be done dynamically (not at login time),
> 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).
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).
Jim McCann
Aug 15, 2023, 12:00:05 PM8/15/23
to
Package: xdg-desktop-portal
Followup-For: Bug #1018880
X-Debbugs-Cc: ix+...@tchow.com
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.
Followup-For: Bug #1018880
X-Debbugs-Cc: ix+...@tchow.com
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.
Vincent Lefevre
Aug 15, 2023, 4:50:05 PM8/15/23
to
On 2023-08-15 11:45:59 -0400, Jim McCann wrote:
> 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:'.
Probably because /etc/X11/Xsession is not used, as you're using you're
> 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:'.
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).
> 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.
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.
0 new messages