Version: 4 (using 4.1.00 (KDE 4.1.0), Arch Linux) Compiler: gcc OS: Linux (i686) release 2.6.25-vanilla After connecting to ksysguardd on a second machine on the same LAN neither the remote machine nor its sensors appear in the sensor-browser. The remote machine is running Ubuntu Dapper with ksysguardd version 1.2.0 package version 4:3.5.2-0ubuntu26. When using ssh ksysguardd is startet on the remote host as normal. When starting ksysguardd -di manually, connecting to it and then killing it, ksysguard shows some error about the lost connection. So the connection seems to be ok, but I simply can not use it.
I can confirm that this problem still exists in 4.1.3. Running 64-bit Kubuntu intrepid, I cannot monitor remote systems. This was not a problem in KDE3. When I attempt to a remote system (using ssh), there are no connection errors, but the remote system never appears in the sensor browser. I can confirm that (performing the manual test mentioned in the ksysguard handbook) if I type "ssh 192.168.0.1 ksysguardd", I can connect to the remote system just fine.
It looks to me like https://bugs.kde.org/show_bug.cgi?id=171525 is a dupe of this bug. Could someone with the power to do so please at least mark this bug as confirmed and, if they agree with me, mark 171525 as a dupe of this one?
I just had a look at the code to find out if this is easily fixable. It does however not appear to be. My impression is that some stuff got lost during the porting to KDE4. Random findings: -- the commented out lines in ksysguard.cc's TopLevel::connectHost() are probably required; the props mentioned should most likely be moved to the TopLevel class -- SensorBrowserWidget doesn't have a method to add new hosts, so it will only ever contain localhost right now
I have sniffed the TCP stream between ksysguardd running as a daemon on a ubuntu 9.04 server and ksysguard running on a kubuntu 9.04 on the same lan. The connection is established and the daemon reply correctly. The client instead never send the "monitors" command to ask for sensors, keeping the connection alive.
Marking as resolved, since it's a duplicate of 171525. The fix for 171525 is also checked in already. *** This bug has been marked as a duplicate of bug 171525 ***