On Mon, Dec 27, 2021 at 10:24 PM Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2021-12-27 at 20:11 +0300, Andrei Borzenkov wrote:
On Sat, Dec 25, 2021 at 12:58 AM Carlos E. R. <> wrote:
I see this in a small laptop upgraded this afternoon to 15.3. I open an ssh session to it, as root, then run:
Legolas:~ # meld /etc/ssh/sshd_config.rpmnew /etc/ssh/sshd_config & [1] 1864 Legolas:~ # [1]+ Done meld /etc/ssh/sshd_config.rpmnew /etc/ssh/sshd_config Legolas:~ #
The program takes 20 seconds to appear, there is a timeout in the log
There are several gaps between messages in log you quoted, which one specifically do you mean?
I think the application starts just here
22:42:07 22:42:33
But I'd better do another attempt and check, because I don't remember. The machine is suspended this instant, so perhaps there may be wake up related messages inserted in the flow.
(desktop is xfce, in case I forgot and is relevant)
Start application here (meld), via ssh (ssh -X root@legolas.valinor):
...
<3.6> 2021-12-27 20:05:29 Legolas systemd 6532 - - Starting Portal service (GTK+/GNOME implementation)... <3.6> 2021-12-27 20:05:29 Legolas xdg-desktop-portal-gtk 6699 - - Unable to init server: Could not connect: Connection refused <1.4> 2021-12-27 20:05:29 Legolas xdg-desktop-por 6699 - - cannot open display: <3.5> 2021-12-27 20:05:29 Legolas systemd 6532 - - xdg-desktop-portal-gtk.service: Main process exited, code=exited, status=1/FAILURE <3.4> 2021-12-27 20:05:29 Legolas systemd 6532 - - xdg-desktop-portal-gtk.service: Failed with result 'exit-code'. <3.3> 2021-12-27 20:05:29 Legolas systemd 6532 - - Failed to start Portal service (GTK+/GNOME implementation).
Here is the delay. Then the application starts and I get all those messages below (and nothing in between):
Service is started by systemd user instance which is not aware of DISPLAY exported by sshd. I tried "systemctl --user import-environment DISPAY" before starting program that triggers xdg-desktop-portal, and that gets rid of "Failed to start Portal service", but I still observe the same 20+ seconds delay before application finally launches. ...
<3.6> 2021-12-24 22:42:07 Legolas dbus-daemon 1029 - - [session uid=0 pid=1029] Activating via systemd: service name='org.freedesktop.portal.Desktop' unit='xdg-desktop-portal.service' requested by ':1.38' (uid=0 pid=1864 comm="/usr/bin/python3 /usr/bin/meld /etc/ssh/sshd_confi")
That is not going to work. You connect via ssh and likely forward X11 connection from remote system to local display. But your login session on the remote system has its own session D-Bus instance which knows nothing about the desktop environment on your client. So your GUI application attempts to invoke services on your client desktop via connection to server D-Bus.
To transparently start applications via ssh X11 forwarding one would need to also forward D-Bus connection. While it is possible to forward D-Bus socket (I tested that it works) security implications are not clear (D-Bus can no longer verify the user that makes the request. All requests will appear to come from the client ssh process).
I confess to not know what D-Bus is, except that I see references to it in the logs since several years ago, complaining of this or that, in every computer. Thus I'm not intentionally doing anything about D-bus. The only thing I know is that there was no delay in 15.2, and there is a long delay in 15.3 :-)
So if the application can work without dbus, and there is a way to tell the application to not try dbus, I suppose I would be happy.
This is the same as asking an application to not try TCP/IP protocol to work around DNS resolution issues. D-Bus is a communication protocol. It is the de-facto standard today for communication between desktop components. You cannot "tell the application to not try dbus". At most you can tell the application to not attempt to contact service that causes delay. But I do not know how to do it. For a start, I do not know why xdg-portal service is invoked at all - all I have seen so far suggests that it should be opt-in. So far the only way to eliminate this delay I found was to forward Unix socket from remote client to local user D-Bus socket and tell remote side to use it. But that sounds horribly wrong for multiple reasons. I suggest you open a bug report to clarify whether this is an upstream issue or caused by the local SUSE patch.
The delay doesn't happen when I run the same command locally.
Of course it does not. In this case you have a consistent desktop environment where your application runs.