Bug 181330 - slow window, missing DBUS from remote KDE4 window
Summary: slow window, missing DBUS from remote KDE4 window
Status: RESOLVED FIXED
Alias: None
Product: kde
Classification: I don't know
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Unspecified
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-19 19:02 UTC by Juergen Mathwich
Modified: 2020-09-28 23:09 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Juergen Mathwich 2009-01-19 19:02:39 UTC
Version:            (using Devel)
Installed from:    Compiled sources

I have to connect to other PCs often and I am used to rely on ssh -X to automatically set the DISPLAY variable using Xorg's remote window features. 
When using this on KDE4 apps (eg kate) i get a few messages complaining about missing DBUS connection. When the window appears it behaves extremely sluggish which makes it impossible to use it. 

....
klauncher(15502) kdemain: No DBUS session-bus found. Check if you have started the DBUS server.
kdeinit4: Communication error with launcher. Exiting!
kdeinit4: preparing to launch /usr/lib/kde4/libexec/klauncher
klauncher(15510) kdemain: No DBUS session-bus found. Check if you have started the DBUS server.
kdeinit4: Communication error with launcher. Exiting!
kate(15359): couldn't create slave: "Keine Verbindung zu klauncher: Not connected to D-BUS server"
....

I know that KDE 4 relies on DBUS for IPC - but could there be a way to re-enable such a basic Unix-Features?
Comment 1 Manuel Amador (Rudd-O) 2009-07-15 00:50:22 UTC
I have the EXACT same problem trying to run a KDE 4 app.  I'm using KDE 4.2 in Kubuntu on the machine where I run the app.

ssh -X machine
ksystemlog &
(bunch of brain farts from the application)
kdeinit4: preparing to launch /usr/lib/kde4/libexec/klauncher                                                   
kdeinit4: preparing to launch /usr/bin/kded4                                                                    
KDE Daemon (kded) already running.
kdeinit4: preparing to launch /usr/bin/kbuildsycoca4
kbuildsycoca4 running...
ksystemlog(4764) KToolInvocation::klauncher: klauncher not running... launching kdeinit
kdeinit4: Shutting down running client.
klauncher: Exiting on signal 15
kdeinit4: preparing to launch /usr/lib/kde4/libexec/klauncher
kdeinit4: preparing to launch /usr/bin/kded4
KDE Daemon (kded) already running.
kdeinit4: preparing to launch /usr/bin/kbuildsycoca4
kbuildsycoca4 running...
ksystemlog(4764): couldn't create slave: "No se puede dialogar con klauncher: Not connected to D-Bus server"
ksystemlog(4764) KToolInvocation::klauncher: klauncher not running... launching kdeinit
kdeinit4: Shutting down running client.
klauncher: Exiting on signal 15
kdeinit4: preparing to launch /usr/lib/kde4/libexec/klauncher
kdeinit4: preparing to launch /usr/bin/kded4
KDE Daemon (kded) already running.
kdeinit4: preparing to launch /usr/bin/kbuildsycoca4
kbuildsycoca4 running...
ksystemlog(4764) KToolInvocation::klauncher: klauncher not running... launching kdeinit
kdeinit4: Shutting down running client.
klauncher: Exiting on signal 15
kdeinit4: preparing to launch /usr/lib/kde4/libexec/klauncher
kdeinit4: preparing to launch /usr/bin/kded4
KDE Daemon (kded) already running.
kdeinit4: preparing to launch /usr/bin/kbuildsycoca4
kbuildsycoca4 running...
ksystemlog(4764): couldn't create slave: "No se puede dialogar con klauncher: Not connected to D-Bus server"

*poof* error.

The application itself does open (though it sends tens of megabytes of data through the LAN, so it's UNUSABLE).  HOWEVER, when any button or menu in the application attempts to open a file open dialog box, the brain fart diarrhea starts again on the console, and after 20 seconds I get an empty file open dialog with a modal error box saying "Could not open slave -- Could not talk to klauncher".

What happened to KDE?  Doing this was a routine thing in KDE 3, guys.

Please confirm this bug, because it is still present today.
Comment 2 bjoernv 2012-10-25 09:47:25 UTC
Missing DBUS on remote apps is probably not the only reason for slow remote KDE apps. 

I managed the following to prevent warnings and errors and to increase the speed of remote KDE apps:
- X11 forwarding without SSH, but with $DISPLAY and Xauth
- starting Dbus, Console-Kit and notification-daemon daemons on the remote site during shell login:
  e.g. with dbus-launch ck-launch-session sh -c "/usr/lib/notification-daemon; bash"
- starting PULSE_AUDIO forwarding
  e.g. with export PULSE_SERVER=client-pc

But in summary I found, that same KDE apps run normal and others are very slow.

Examples:
Normal: Kwrite, Dolphin, Kaffeine
Slow, Xorg CPU intensive: Kate, Amarok

It's difficult to debug and to find causes for slowness of each KDE app. Probably tools like Wireshark, Ltrace and Strace can help. Slow apps show a lot of traffic (function calls, network traffic), but this is very low-level information. Unfortunately the application developers are probably not very interested in tuning their apps for remote X11 use.
Comment 3 Andrew Crouthamel 2018-11-09 00:59:23 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 4 Andrew Crouthamel 2018-11-18 03:30:34 UTC
Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand.

Thank you for helping us make KDE software even better for everyone!
Comment 5 Nate Graham 2020-09-28 23:09:57 UTC
No response; assuming it was fixed since then.