On 28/12/2021 08.28, Andrei Borzenkov wrote:
On Mon, Dec 27, 2021 at 10:24 PM Carlos E. R. <> wrote:
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:
...
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.
ok, so that is not the cause.
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.
Well, maybe I miss something obvious, but AFAIK, when working over ssh dbus doesn't work, yet the application works fine, so why even try?
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.
Ok, will do.
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.
Still, desktop belongs to user "cer" and application is run as root. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)