VNC randomly freezes after upgrade to 15.1

English Network/Internet
1

Can anyone help please?
My VNC sessions started to hang randomly; sometimes it hangs after few minutes after logging (VNC -> gdm -> KDE), sometimes the session lasts for tens of minutes but it always hangs up at some point. There is no discernible pattern what behavior causes it, it frequently happens after opening Firefox window, or after a brief browsing; when moving Dolphin window, or when opening the Plasma launcher menu.
VNC is practically unusable for me.
This issue started after upgrading to openSuse Leap 15.1 on my home server.
When VNC hangs up, the VNC client does not closes or reports any issue, it is just stay “frozen”, turning into a static picture, a snapshot, of my last activity. Only cursor moves and even keeps the last shape (like when it froze during window move the cursor stays in window moving shape).

The ssh connection is unaffected and I can still use the command line, server is responding; doesn’t look like a network issue.

Details:

I use vncmanager configured as per openSuse manual.


$ systemctl status vncmanager
● vncmanager.service - VNC manager
   Loaded: loaded (/usr/lib/systemd/system/vncmanager.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2019-09-20 18:34:13 BST; 4h 1min ago
 Main PID: 1078 (vncmanager)
    Tasks: 8 (limit: 4915)
   CGroup: /system.slice/vncmanager.service
           ├─1078 /usr/bin/vncmanager
            └─2475 /usr/bin/Xvnc -log *:syslog:30,TcpSocket:syslog:-1 -inetd  -MaxDisconnectionTime=5 -securitytypes=none -displayfd 10 -geometry  1024x768 -AllowOverride=Desktop,Acc>

Display manager: gdm
Window manager: KDE Plasma
I tried LightDM recently but it failed to show user logging screen - I will create a separate post about that.
I enjoyed a good VNC service before recently upgrading to 15.1, all on the same hardware and setup.
The leaves no trace in /var/log/messages (yeah, I still use rsyslog).
I cannot find any other vnc or Xorg related log. There is no .xsession-errors error file generated.
I tried restarts, reboots, restarting display manager via systemd - to no avail, the issue is still there.

2

The recommended alternative DM for KDE/Plasma is Lightdm, not gdm.
I assume by “loggin screen” you actually mean “login screen,” with input fields for username and password for a specified User account.
You say your machine was upgraded, do you know what DM you were using before you upgraded, was it SDDM, GDM or LightDM?
How are you switching between DMs? Are you using the YaST /etc/sysconfig editor or making entries manually in /etc/sysconfig… Which you should not be doing(no longer supported), or are you using update-alternatives(The new way)?

TSU

3

Some positive news: if I set permanent VNC session, and the VNC session freezes again I can simply close VNC viewer (client) window and open it again.
It offers me to re-join my session as if nothing happened. All is live and well on the other side. It works 100%. Of course it’s going to hang up
again at some point, which can be in the next minute or after several hours. Vncmanager and its permanent saves the day. This freeze-ups are still
very annoying but at least VNC it’s now VNC in “usable” territory now.

I use TigerVNC Viewer, Windows OS, as the client. I tested TightVNC (open source), RealVNC (free version) and UltraVNC (open source) but none of them
provide “Auto-resize Remote Display” aka “Resize remote session to the local window”, only TigerVNC. I use “Auto-resize Remote Display” a lot, it’s
the must have feature for me. And I am suspicious that what possibly makes VNC freezing, though there is no direct, observable connection.

When VNC freezes, the picture stays static, it’s clearly visible on the KDE clock, it’s not updating. I observed the frozen VNC viewer window
for 10 minutes but, no updates, no back to life, nothing.

I set TigerVNC to debug level logging with: “C:\Program Files\TigerVNC\vncviewer.exe” -Log *:file:100
But I cannot any see any error in “C: emp\vncviewer.log”, anything suspicious. Messages are added even after session freeze.

TigerVNC Viewer itself appears to be well and live, not crashed, or frozen or hanged up. Last log messages were written several minutes after session
had frozen. Also the visual bandwidth meter, which is displayed automatically when TigerVNC Viewer is in debug mode, is also visibly working even after
session have frozen. You can see the last spike of network activity slowly drift away to the left.

The recommended alternative DM for KDE/Plasma is Lightdm, not gdm.

Yes, I know. It tried LightDM recently but it failed to log me remotely in. I suspect the openSuse version have some issue with XDMCP.
I created another tread for this issue:
https://forums.opensuse.org/showthread.php/537605-LightDM-does-not-work-with-VNC-logging-login-page-not-displayed-for-remote-client?p=2914925
https://bugzilla.opensuse.org/show_bug.cgi?id=1151530

I always used GDM and it always worked for me. It worked before I upgraded my distro to 15.1.
The issue with VNC stated immediately after the upgrade.

How are you switching between DMs?

I tried both Yast2, “Miscellaneous -> Alternatives”, and in CLI using alternatives

update-alternatives --config default-displaymanager

Always restaring DM with:

sudo systemctl restart display-manager

As per manual: SDB:Change Display Manager - openSUSE Wiki

I started to play with LightDM only after the freezing issues started to appear. Hope that LightDM might fix it was my motivation to even try. So the DM switching cannot be the culprit. And I am doubtful that is related to GDM too. I will give LightDM another chance, it’s definitively on my TODO list.

4

You might try capturing packets and events in real time…
Especially since your display freezing appears to happen regularly and often but does not seem to affect the running session.

Capture system events
On each end, leave an elevated console running the following

forunalctl -f

To capture packets on each machine, run tcpdump and then view the file later in wireshark.

Consider if the connection between the machines is being broken, the QoS can be very low.
So, for instance if you’re seeing problems across a WAN link, run some tests withthe same machines within the LAN.

TSU

5 
forunalctl -f

You probably meant journalctl. “journalctl -f” does tailing of the system log. Same data I can see in /var/log/messages. I must admit it’s more practical to see syslog updates “live” then constantly going to “/var/log/messages”.
But the result is still the same :frowning: There is no smoking gun there.

About packet capturing and tcpdump. Hmm, isn’t VNC a binary protocol? Crack the packet content would be very hard even if you know the VNC data format. I would leave that as a last desperate option.

My intensive testing brought some positive results:

  • I can now reproduce the freezing deterministically and fast - with VirtualBox GUI, a unsuspecting Qt app. Just by switching tabs in Settings very fast, so the rendering starts to lag, leading to the freeze.
  • If I enable JPEG compression on the client side, the stability improves drastically. It’s a bit contra-intuitive, making it more complex makes it more stable.
  • When JPEG compression (quality = 8) is enabled and ZRLE encoding is selected (not the default “Tight” encoding) - I haven’t experiences a single freeze so far!

Please check details in the bugzilla: 1151528 – VNC sessions started to hang randomly after DUP to 15.1

It really looks to me that they have a bug there and that it 's most likely a regression in 15.1. I guess I’ll leave it for the bugzilla and for someone from openSuse to pick it up. Thank you for your help!

6

I updated to Leap 15.1 yesterday and am having the same issue using UltraVNC viewer. As yet I’ve not done any diagnostics as I don’t use this very much. However I did have a couple of secondary issues as a result of a hang. One was that, having logged in as root, when I tried to log in as root again the login was accepted but instead of starting the session it simply came back to the login again. The second was that a number of processes were left around, one of which was Firefox, and that started using a lot of CPU (because it had nowhere to output data?) and that caused the rtkit-daemon to complain about the canary thread needing fixing.

7

Could the power settings have been changed, could your machine going to sleep
Maybe start looking for anything that could interrupt the session for instance the lock screen

TSU

8

I had a similar problem with vncmanager so I went back to the old x11vnc - works fine with UltraVNC to autoscale.
Here is my script - you have to start it on the server to work.
I log everything to x11vnc.log and keep an old one just in case.

change userid to your userid and password to what password you want. If you want the main screen set the display to :0 if you want a different one set it :1
:0 = 5900 :1 = 5901 to UltraVNC
you need to disable vncmanager for this to work - systemctl stop vncmanager - you can add that to the script if you don’t want to disable it.

#!/bin/bash
touch ~userid/x11vnc.old
rm -f ~userid/x11vnc.old
mv ~userid/x11vnc.log ~userid/x11vnc.old
/usr/bin/x11vnc -nap -wait 50 -noxdamage -passwd password -display :0 -forever -o ~userid/x11vnc.log -bg