On 28/12/2021 15.50, Andrei Borzenkov wrote:
On Tue, Dec 28, 2021 at 2:24 PM Carlos E. R. <> wrote: ...
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?
Complain to desktop developers. Linux desktops became rather complex and need much more than just a plain X11 server to work. Apparently nobody is motivated enough to design "desktop application forwarding". Personally when I need GUI I just start VNC. Unfortunately, even that fails because developers are not willing to support more than one graphical session per user ... I wonder if I can start "virtual seat" so that two sessions do not conflict.
:-( I don't want to start whole GUI sessions remotely, just terminals and applications. Can have several terminals from several machines and repeat ops on each. Several GUI sessions is a nightmare. We are going to looe a pro point against windoze :-(
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.
Please post bug number here.
Yes, yes, will do, but patience, I have several problems dancing around me at the moment...
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.
How are we supposed to know what you did? You said "I run the same command" and the command was "meld". You did not say "I used su or sudo to run this command as root" which is implied now.
Nonono, I don't use sudo or su (with the problem). I use "ssh -X root@machine", from another machine in same LAN. The laptop is running a local sesion as user cer, obviously, but I don't use it. It is just half a metre away, tiny keyboard and display, so I prefer big display and do maintenance on it via ssh from main computer. Have done that for many years. I simply tried meld locally on that machine for verification: on local session, as cer, do "su -", then run the same meld command as I did via ssh. It is in the bash history.
I can reproduce your issue when ssh into a local host and different user or doing "su - otheruser". In both cases I get the same delay. If you provide exact steps when issue does *not* happen, we could test it.
Ok, on local session and seat (can't copy paste, mail is on another computer): cer@legolas:~> su - legolas:~# su - legolas:~# meld /etc/ssh/sshd_config /etc/ssh/sshd_config No delay, just 2 or 3 seconds, as expected from puny CPU. Typing on main computer, use ssh to Legolas: cer@Telcontar:~> cer@Telcontar:~> ssh -X root@legolas.valinor Last login: Mon Dec 27 20:07:52 2021 from 192.168.1.14 Have a lot of fun... Legolas:~ # meld /etc/chrony.conf /etc/chrony.conf & [1] 11560 Legolas:~ # A long delay. I count to 30 on my mind. Could use a stopwatch to be precise if needed. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)