Xstartup.turbovnc

0 views

Skip to first unread message

Zoraida

unread,

Aug 3, 2024, 6:10:58 PM8/3/24

to peutagorpink

TurboVNC is a high-performance VNC implementation derived from TightVNC. It provides both VNC server and VNC viewer functionalities. According to the official site, it is better than TigerVNC in multiple aspects [1].

Simply runing vncserver as the normal user that will later use VNC, and you will be prompted to set a password. Then configure which desktop environment to use in /usr/bin/xstartup.turbovnc. For example, edit the file below as root to use KDE plasma:

You can also use any different file than /usr/bin/xstartup.turbovnc with the -xstartup FILE option of vncserver to avoid modifying the script provided by the package.Then run vncserver again to start it, you should see it binds to the port 5901. You should always wrap it in a SSH tunnel as what is done with any other VNC software(see TigerVNC#Accessing vncserver via SSH tunnels).

unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESSIs this still required, in particular on Linux Mint 17 MATE (which is a GNOME 2 fork) or are these legacy requirements? What happens if these env vars are set or unset?Thanks.

TigerVNC no longer uses xstartup or supports multiple simultaneous Xvnc sessions under the same user account, so this is no longer relevant for TigerVNC. But I had to dig into the issue for TurboVNC 3.0, so I can definitely explain. :)

In order to run multiple Xvnc sessions under the same user account (assuming that all of the sessions will use a reasonably modern window manager), it is necessary for each Xvnc session to have a separate D-Bus session bus instance. On Red Hat/Fedora (and derivatives), SuSE/openSUSE, FreeBSD, and Solaris 11, xinitrc and Xsession automatically create a new session bus instance if the DBUS_SESSION_BUS_ADDRESS environment variable is empty. This is why xstartup.turbovnc and TigerVNC's xstartup file unset that environment variable, historically speaking.

I discovered that this is insufficient on recent Debian-compatible systems (specifically Ubuntu 18.04+ and whatever the Debian equivalents are.) On those systems, it is necessary to explicitly create a new session bus instance using dbus-launch. (Refer to , which should work properly for all window managers listed here: )

Unsetting SESSION_MANAGER is necessary if you are attempting to start an Xvnc session running GNOME/MATE from inside of an existing GNOME/MATE session. If the X startup script does not unset SESSION_MANAGER, then the new GNOME session will pick up the value of SESSION_MANAGER from the old GNOME session, and the two sessions will interfere.

I have been using the TurboVNC server (running on Centos, Ubuntu, and Windows) together with the RealVNC client since many years with extreme satisfaction. However, due to updating and changes in the system I am now encountering two ill-defined problems depending on the machine and OS (centos or Ubuntu) I use:

1) On connecting to the server (ubuntu) I receive some messages about 'Keyring' and only can proceed when entering the password on the server to close the 'Keyring' panel. Once done, there is no further problem but on reboot I have to do it again, which requires to be physically present at the server.

2) When starting turbovnc server (centos) as normal user and connecting from remote I only get a grey screen sometimes with stripes. When starting turbovnc server as root it works as expected but I am then root for everything I do, which is not really good.....

Specifically which versions of the operating systems and TurboVNC are you using? If you are trying to use a window manager other than the default (GNOME 3) on recent CentOS and Ubuntu releases, then please specify the window manager you are trying to use.

Also, you'll get a lot better performance with the TurboVNC Viewer than with the RealVNC Viewer. :) The compatibility intersection between RealVNC and TurboVNC (or TigerVNC, for that matter) includes only old and sub-optimal RFB encoding methods. RealVNC doesn't support Tight encoding, much less the accelerated version of it that TurboVNC uses, and it also doesn't support the RFB flow control extensions (which are used to improve performance on high-latency networks.)

To exclude problems possibly due to the different Linux versions (the Centos on one PC is 6.10 and refuses installation of the newest TurboVNC version as it has passed its EOF) I now installed the most recent version of TurboVNC on my laptops, both running Ubuntu mate 20.04 with Metacity (Marco), as reported by "wmctrl -m". I started with "/opt/TurboVNC/bin/vncserver -geometry 1870x980'". When connecting from one to the other, regardless from which direction, I get a black screen with the message: "Could not acquire name on session bus!" Exactly the same occurs when I use the RealVNC client. So, I guess, it has to do with the setup of the TurboVNC-server.

As already stated previously, I have been using this precise setup successfully from Ubuntu-10.04 onwards with the respective latest versions of TurboVNC. I must say that that I had similar problems in the past but some painful tinkering eventually solved it. However, I never found out the reason! For example, it might have been PATH, Keyring, or what else. Once running I usually avoided by all means to reboot and start again trying out things....

How is the installation refused on the CentOS 6 machine? TurboVNC 2.2.x is still built with a CentOS 5 Docker container, so it should install on CentOS 6 with no problems. Even TurboVNC 3.0 is built with a CentOS 6 Docker container, so it should work as well. Referring to and , I specifically tested CentOS 6 with TurboVNC 2.2.x stable and 3.0 evolving.

I now installed the most recent version of TurboVNC on my laptops, both running Ubuntu mate 20.04 with Metacity (Marco), as reported by "wmctrl -m". I started with "/opt/TurboVNC/bin/vncserver -geometry 1870x980'". When connecting from one to the other, regardless from which direction, I get a black screen with the message: "Could not acquire name on session bus!" Exactly the same occurs when I use the RealVNC client. So, I guess, it has to do with the setup of the TurboVNC-server.

On modern Ubuntu releases, it is generally necessary to start MATE explicitly, by passing '-wm mate-session' to /opt/TurboVNC/bin/vncserver or specifying '$wm = "mate-session";' in turbovncserver.conf. That's why I referred you to , which instructs the reader to do that. On Ubuntu 18+, attempting to start MATE through xinitrc or Xsession (which is what xstartup.turbovnc will do if -wm/$wm is not specified) will only work if there is no other instance of MATE already running. xstartup.turbovnc unsets DBUS_SESSION_BUS_ADDRESS, which normally causes every instance of MATE to use a separate DBus address. However, /etc/X11/Xsession.d/20dbus_xdg-runtime, which is invoked by either Xsession or xinitrc, explicitly sets DBUS_SESSION_BUS_ADDRESS to unix:path=$XDG_RUNTIME_DIR/bus. That means that every MATE instance will share the same DBus address, and the second and subsequent instances will error out with "Could not acquire name on session bus!".

I can now connect perfectly well from the Lenovo W520 to the Lenovo ideapad-miix-320-10icr BUT in other direction I still get a black screen with the error I detailed before. This is very strange as both PCs have the same OS, I run an upgrade, I made the changes to the turbovncserver.conf file, I restarted them but still the error persists!

No, you just need to switch your CentOS YUM repository URLs so that YUM uses the vault.centos.org repository. That is always necessary when using CentOS releases that are past EOL. That issue is unrelated to TurboVNC. You can still install the TurboVNC RPM directly, without using YUM, or you can simply disable the CentOS YUM repositories, and the TurboVNC YUM repository will continue to work.

to /opt/TurboVNC/bin/vncserver on the machine that isn't working. It really does appear, from the log, that it is trying to run xinitrc instead of mate-session, so perhaps there is a typo in turbovncserver.conf.

The visualization servers are intended for single-process pre- and post-processing only, as well as GUI monitoring of running jobs. These servers are NOT intended for parallel processing or running compute tasks. The system administrators will terminate processes that do not fit the above description without warning. However, it is now possible to get a Virtual Desktop on a compute node, where you can use the full capabilities of the compute node without restriction.

TurboVNC by default sets up a startup file that selects the lightweight window manager Fluxbox. If you are running TurboVNC on chpcviz1 or chpclic1 you can also use the friendlier window managers Mate or XFCE4.

More than one VNC session can be run simultaneously. In this example, two other sessions are already running, therefore :3 is used to specify that this will be a session on virtual display 3. If this is unavailable, try :4, etc. Optionally specify an appropriate display resolution and colour depth, as in the above example. If you get a warning of unsupported resolution, try one of the standard resolutions. The port number used for a VNC session is 5900+n , where n is the number of the display. In this example, the VNC session will be served on port 5903.

Any VNC client can be used to connect to the TurboVNC server on chpcviz1. However, to take full advantage of the higher speed and configuration options of TurboVNC, use the TurboVNC client as well. It can be downloaded from . The Windows installer includes a customized version of PuTTY. Once TurboVNC has been installed, run the PuTTY in the TurboVNC installation directory. In the left pane, expand the SSH option, and click on Tunnels. Add the port number for your local host in the source port box, and chpcviz1:5903 (use the port number that your VNC server is using) in the destination box.