since several updates of Tumbleweed I can no longer log onto remote machines via TigerVNC.
The client always outputs “The connection was dropped by the server before the session could be established.” So I checked the server status and found a strange output as described below:
When I run this command, there is always a line starting with “Until: …”. What is this telling me ? From the timestamp I suspect a kind of timeout so that remote logging in is blocked:
notebook3:/etc # systemctl status xvnc.socket
● xvnc.socket - Xvnc Server
Loaded: loaded (/usr/lib/systemd/system/xvnc.socket; enabled; preset: disabled)
Active: active (listening) since Thu 2023-02-16 16:50:37 CET; 16min ago
Until: Thu 2023-02-16 16:50:37 CET; 16min ago
Listen: [::]:5901 (Stream)
Accepted: 19; Connected: 0;
Tasks: 0 (limit: 4915)
CPU: 4ms
CGroup: /system.slice/xvnc.socket
Feb 16 16:50:37 notebook3 systemd[1]: Closed Xvnc Server.
Feb 16 16:50:37 notebook3 systemd[1]: Stopping Xvnc Server…
Feb 16 16:50:37 notebook3 systemd[1]: Listening on Xvnc Server.
I copied the file tigervnc to /etc/pam.d, restarted xvnc.socket. But no luck. The file tigervnc does indeed exist in that directory in an an older snapshot of tumbleweed (where xvnc works fine).
I’m still wondering what is meant by “Until: Sat 2023-02-18 08:46:18 CET; 2min 32s ago” (see my first post above).
This is a bug in the current systemd. This field is valid only for the service or scope units and corresponds to RuntimeMaxSec directive, but apparently systemctl prints it for all other unit types.
The value is time when service was started plus the value of RuntimeMaxSec. For supported types systemd correctly initializes it to default infinity, but for everything else it stays at zero which is not the default and so is printed.
So the systemd-issue has been solved. But tigervnc itself still doesn’t work.
I copied the file tigervnc to /etc/pam.d but no luck.
What am I doing wrong ?
TigerVNC Viewer 64-bit v1.12.0
Copyright (C) 1999-2021 TigerVNC Team and many others (see README.rst)
See https://www.tigervnc.org for information on TigerVNC.
Mon Apr 24 16:07:23 2023
DecodeManager: Detected 4 CPU core(s)
DecodeManager: Creating 4 decoder thread(s)
CConn: Connected to host 192.168.4.4 port 5901
CConnection: Server supports RFB protocol version 3.8
CConnection: Using RFB protocol version 3.8
CConnection: Choosing security type VeNCrypt(19)
CVeNCrypt: Choosing security type X509None (260)
Mon Apr 24 16:07:25 2023
CConn: End of stream
CConn: The connection was dropped by the server before the session could be established.
The problem is related to the “auto-login” feature. On system startup a dedicated user is auto-logged on the server machine. This seems to be blocking tigervnc. If that user logs off, then tigervnc works fine. So I disabled the “auto-login” and everything behaves as it should.