On Sun, 16 Feb 2020 20:12:55 +0100 "Patrick Dupre" wrote:
vncviewer -via pdupre@euripide :1
Very good, I get
...
I can connect, but I just get a xclock.
Probably due to half brojen VNC session:
lsof -i tcp:5901 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME Xvnc 10283 pdupre 6u IPv4 203381 0t0 TCP *:5901 (LISTEN) Xvnc 10283 pdupre 7u IPv6 203382 0t0 TCP *:5901 (LISTEN)
This is probably the vncserver@:1.service that failed to stop properly.
Kill this Xvnc process and start again vncserver@:1.service.
I made vncserver -kill :1 and vncserver :1
New 'euripide:1 (pdupre)' desktop is euripide:1
Starting applications specified in /home/dupre/.vnc/xstartup Log file is /home/dupre/.vnc/euripide:1.log
cat .vnc/xstartup unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS exec /etc/X11/xinit/xinitrc
cat .vnc/euripide:1.log
Xvnc TigerVNC 1.10.0 - built Jan 13 2020 09:18:23 Copyright (C) 1999-2019 TigerVNC Team and many others (see README.rst) See https://www.tigervnc.org for information on TigerVNC. Underlying X server release 12005000, The X.Org Foundation
Sun Feb 16 20:43:35 2020 vncext: VNC extension running! vncext: Listening for VNC connections on all interface(s), port 5901 vncext: created VNC server for screen 0 The XKEYBOARD keymap compiler (xkbcomp) reports:
Internal error: Could not resolve keysym XF86MonBrightnessCycle Internal error: Could not resolve keysym XF86RotationLockToggle
Errors from xkbcomp are not fatal to the X server
Sun Feb 16 20:44:31 2020 Connections: accepted: [::1]::33840 SConnection: Client needs protocol version 3.8 SConnection: Client requests security type VeNCrypt(19) SVeNCrypt: Client requests security type TLSVnc (258)
Sun Feb 16 20:44:42 2020 VNCSConnST: Server default pixel format depth 24 (32bpp) little-endian rgb888
Sun Feb 16 20:45:01 2020 ComparingUpdateTracker: 0 pixels in / 0 pixels out ComparingUpdateTracker: (1:-nan ratio)
Sun Feb 16 20:52:31 2020 Connections: accepted: 193.52.235.60::57174
Sun Feb 16 20:52:33 2020 SConnection: Client needs protocol version 3.8 SConnection: Client requests security type VeNCrypt(19)
Sun Feb 16 20:52:35 2020 SVeNCrypt: Client requests security type TLSVnc (258)
Sun Feb 16 20:52:43 2020 VNCSConnST: Server default pixel format depth 24 (32bpp) little-endian rgb888 VNCSConnST: Client pixel format depth 8 (8bpp) bgr233
Sun Feb 16 20:52:44 2020 VNCSConnST: closing [::1]::33840: Clean disconnection EncodeManager: Framebuffer updates: 5 EncodeManager: Tight: EncodeManager: Solid: 4 rects, 3.09043 Mpixels EncodeManager: 64 B (1:193153 ratio) EncodeManager: Total: 4 rects, 3.09043 Mpixels EncodeManager: 64 B (1:193153 ratio) TLS: TLS session wasn't terminated gracefully TcpSocket: unable to get peer name for socket Connections: closed: ::0 ComparingUpdateTracker: 0 pixels in / 0 pixels out ComparingUpdateTracker: (1:-nan ratio)
(This connection is not secure).
Wrong message from vncviewer. It's secure bcause goes through the SSH tunnel
Any gnome session is started (like with remmina).
remmina, as vncviewer, only connect to the VNC session.
It seems that something is missing, but the .bashrc are identical on both machines which are running the same version of fedora.
As said before:
- this is the ~/.vnc/xstartup file that determines what session to spawn.
- running two gnome-session on the same machine will probably not work.
I always run remmina in VNC viewer mode, in ssh tunnel
That should do the same as "vncviewer -via"
-- francis _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org