Mailinglist Archive: opensuse (686 mails)

< Previous Next >
Re: [opensuse] Kate unusable in 12.3 via ssh remote login
On 07/10/2013 11:13 AM, John Andersen wrote:
On 7/10/2013 2:46 AM, Dave Howorth wrote:
John Andersen wrote:
There may be more Xserver issues there than meets the eye.

While testing this bug, I logged into a OS 12.3 laptop via ssh from
another machine (windows), and ran the tests. When I had ascertained
that the original report was true, it was very slow.

I went over to that lap top to verify it worked correctly there.

Then I logged out of the lap top.

Then Logged back in again, and the KDE desktop showed up NOT on the
LAPTOP, but on the Windows machine I had previously tested from.

Couldn't believe my eyes, so I repeated the test, and it happened the
same way again. If there is an existing xsession on a remote machine,
and you log in on the local machine, your X session goes to the
remote machine.

Nothing but a reboot will fix that.
That does sound very bizarre, and very worrying.

Can you clarify something please. You wrote "I logged into a OS 12.3
laptop via ssh" which sounds like you opened a remote connection in a
terminal. But then you wrote "If there is an existing xsession on a
remote machine", which is something completely different.

Do you mean that you did have a remote xsession, or do you mean you just
had a remote X connection and were being sloppy with words?

Ok, let me try again.

Here is the setup:
Laptop running OpenSuse 12.3 and KDE. Logged in as user ME. Sitting at the
KDE desktop.
Windows machine running Win7 and an X Server Package with SSH client.
( package).

FROM WINDOWS, I open an SSH connection to the Laptop and log in as ME (same
Via that SSH connection I open an xterm, which appears on the Windows X Server
and works fine.
I launched Kate, to test out the reported problem. (Slow as hell). Then I
Exited Kate, back to the Xterm.

While the Windows machine still had an X Server session open (same user ME),
just running xterm:
I stepped over to the laptop, and selected Logout, returning to the Login
screen (kdmgreet).
(This shuts down the laptop's X Server for user ME, and terminates all
subordinate programs.

I then logged in again as ME on the laptop.
I saw the Login progress display showing, as each step of the normal KDE
login progressed
(hardrive icon, tools icon, world icon, etc... the Default OpenSuse KDE
login progress indicator)
The desktop(All of them!), the panel, the Activities (a weather indicator and
a calculator), all appeared
on the WINDOWS machine's X Server.

These desktops, and panel are FULLY Functional on the windows machine.
I can click the Application Launcher and launch programs which appear on the
Windows machine.

The Laptop just shows an empty screen with some generic opensuse wallpaper
and a mouse pointer.
The mouse pointer moves with the mouse attached to the laptop, but it does
not respond to left or
right clicks and the keyboard does nothing.

So the new login session invoked at the LAPTOP Suse Machine was sent across the
ssh connection and opened
on the Windows Machine's X Server.

I hope that is Clearer. If not, I will have to shoot a video or something.

This will ONLY happen for me if I first Lunch KATE on the Windows machine (from
the xterm that I
had started from windows).

If I don't launch Kate from the xterm on the windows machine, but simply do
some other things (xeyes, dolphin)
etc, then on the Laptop's KDE session, I can log out and log back into the
Laptop (at the laptop keyboard)
and everything will work as expected, with KDE launching and running on the
Laptop screen.

HOWEVER, once I launch KATE (and apparently ONLY Kate) from the X Server on
EVERY subsequent login to KDE on the Laptop itself, will send the KDE session
to the Windows X Server.

And if I shut down the X Server running on the Windows machine, then attempt to
log in on the
laptop, the KDE progress indicators (disk, tools, world) appear, but when it
gets to the K (kde)
it shows no desktops, Panels, or activity widgets anywhere (not on either

Yet switching to a a console on the laptop (Ctrl Alt F2) I log in and see Kwin,
Klauncher, etc running)
for user ME.

So KATE seems to be trashing the DISPLAY setting or something.

Interesting. I think that kate may be only the tip of the bug. I've been
other strange things too. I'm still poking about, but will list them here in
they ring bells elsewhere.

First, I think that kwrite is involved too. The lagging isn't as bad, but it's

Second, if I log into the remote system using a user account that hasn't been
from the console, I get a different indication. When I run "kate" this error

wolfgang@pharm-5:~> kate
kate(27750)/kdeui (kdelibs): Session bus not found
To circumvent this problem try the following command (with Linux and bash)
export $(dbus-launch)
KCrash: Application 'kate' crashing...
KCrash: Attempting to start /usr/lib64/kde4/libexec/drkonqi from kdeinit
Warning: connect() failed: : No such file or directory
KCrash: Attempting to start /usr/lib64/kde4/libexec/drkonqi directly
drkonqi(27753)/kdeui (kdelibs): Session bus not found
To circumvent this problem try the following command (with Linux and bash)
export $(dbus-launch)

If I then run "export $(dbus-launch", kate will start but is laggy. So I put
the export
command in my ~/.bashrc and wouldn't have to run it again.

But I then noticed that exiting the ssh session would hang as if there was a
process. A control-c would then exit. But there was a whole pile of programs
processes left orphaned. One of them was regarding fuse. So I uninstalled the
package, which still leaves lots of other processes. Another one is:

/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session

These would accumulate with successive logins, with different numbers. I guess
"export (dbus-launch) kicks these off and they don't die.

So then I noticed that this effect doesn't happen when logging in remotely as a
who has run kde from the console. That process creates ~.dbus/session-bus into
a hex string is placed for each login. But kate still lags even for these
users. But
when this user exits no lingering processes are left. So, it would seem that
the dbus-daemon
is the keystone for all these leftover process that I see when having to run
"export $(dbus-launch)
manually. If I create .dbus/session-bus manually it doesn't help.

I've noticed more, but this is all complicated enough as it is, and I need to
dig some
more. The dbus thing may not even be the cause of kate's problem, but who

Other probably unrelated effects include a slowdown of X between the remote and
boxes and a corruption of X screen painting in applications on the local box.


To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups