JustAnother
Apprentice
Joined: 23 Sep 2016
Posts: 185
|
 Posted: Tue Mar 17, 2020 3:05 am Post subject: Tigervnc Puts the Bite on Xfce4 |
 |
|
-> I have three computers with Gentoo. Call them m1, m2, m3.
-> I put tigervnc with server option on all three.
-> I started sway on m2 and ran vncviewer m1:1. This should run xfce4 on m1 and display it on m2.
-> It brought up xfce4 perfectly -- one time. I used the File/LogOut menu to kill it.
-> After that, when I reran vncviewer all I got, after the vncviewer password screen,
was a blank screen with one fast flash of something.
-> I restarted sway on m2. Nope.
-> I tried to sign off/sign on on m2. Nope.
-> I rebooted m2. Nope.
-> I started i3 on m2. Nope.
-> It appears that something in xfce4 breaks after the first use in vncviewer,
possibly having something to do with using the File/Logout popup window vs. killing the entire window.
-> Tried this from m1, with no vncviewers running on m2 or m3:
| Code: | root%emerge:~$ /etc/init.d/tigervnc restart
* Caching service dependencies ... [ ok ]
* Stopping TigerVNC server ... [ ok ]
* Display :1 appears to be already in use because of /tmp/.X11-unix/X1
* Remove this file if there is no X server genny:1
* ERROR: tigervnc failed to start |
-> It may or may not be necessary to rm /tmp/.X11-unix/X1, but it appears to be
necessary to restart tigervnc. Otherwise, a blank screen appears after the vncviewer
password screen, IF the sfce4 File/Logout menu is used. If the window is simply killed
e.g., using alt-sh-Q in sway, then there is no need to restart tigervnc on the server.
Vncviewer will restart ok.
-> So it looks like:
running xfce4 on a tigervnc server m1 from a client machine m2,
and exiting the client xfce4 by using File/Logout & confirm,
leaves a blank tigervnc window on the client m2, and
leaves a pipe /tmp/.X11-unix/X1 on the server m1 in an improper state,
requiring /etc/init.d/tigervnc restart on m1 to burp the server and get things working again,
and possibly a demand to rm /tmp/.X11-unix/X1 on m1.
The problem here is that except for that possible warning from /etc/init.d/tigervnc, there is no
obvious reason for this lockup. I got lucky catching this, as most tigervnc restarts
don't say anyhting - it just restarts. Otherwise I wouldn't have a clue as to what is going on.
I would just have a broken and unusable vnc client.
-> I tried the same test with m2 as the server, and m1 as the client. Same problem, same fix.
-> On the server:
| Code: | cat /etc/conf.d/tigervnc
# Config file for /etc/init.d/tigervnc
# Specify the user(s) Xvnc(1) should be run for. The syntax is: "username:display".
# example: "DISPLAYS="foo:1 bar:2" You can specify more users separated by space.
DISPLAYS="me:1"
# Specify any of vncserver(1) and Xvnc(1) options. See the respective man pages for more information.
# VNC_OPTS=""
cat .vnc/xstartup
#!/bin/sh
#unset SESSION_MANAGER
#unset DBUS_SESSION_BUS_ADDRESS
#exec /etc/X11/xinit/xinitrc
startxfce4 --with-ck-launch & |
This is kind of a serious bug that will turn some people off on using tigervnc, which otherwise seems to work well, at least thusfar.
I've had other mysterious things come up with xfce4, but this looks more like a vnc bug, or some kind of interfacing mismatch. |
|
Desktop Environments
