On 2/11/21 12:50 AM, Dieter Blaas wrote: > > Thank you very much! > > 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) > 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 https://turbovnc.org/Documentation/Compatibility22 and https://turbovnc.org/Documentation/Compatibility30, 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 https://turbovnc.org/Documentation/Compatibility22, 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!". > 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.... > > Thanks again for providing this great software and for your help, > > Dieter > > ------------------------------------------------------------------------ > Dieter Blaas, > Max Perutz Laboratories > Medical University of Vienna, > Inst. Med. Biochem., Vienna Biocenter (VBC), > Dr. Bohr Gasse 9/3, > A-1030 Vienna, Austria, > Tel: 0043 1 4277 61630, > Mobile: 0043 699 1942 1659 > e-mail: [email protected] > ------------------------------------------------------------------------ > On 10.02.2021 18:13, DRC wrote: >> >> 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. >> >> If you haven't already, I would suggest upgrading to the latest >> stable TurboVNC release (2.2.5), removing ~/.vnc/xstartup.turbovnc, >> and restarting the TurboVNC Server. This is sometimes necessary when >> upgrading the operating system, because the TurboVNC Server will >> re-create a default version of ~/.vnc/xstartup.turbovnc if it doesn't >> exist, and the default xstartup.turbovnc that the server creates may >> contain new window manager compatibility fixes. (NOTE: TurboVNC 3.0 >> will use a system-wide xstartup.turbovnc script, so this process >> won't be necessary anymore.) Also refer to >> https://turbovnc.org/Documentation/Compatibility22 for instructions >> on how to launch specific window managers on specific operating >> systems and the known issues with each. On CentOS 7 specifically, >> you have to pass -wm gnome-session to /opt/TurboVNC/bin/vncserver or >> set $wm = "gnome-session"; in In ~/.vnc/turbovncserver.conf or >> /etc/turbovncserver.conf in order to use GNOME 3 (yet another thing >> that will be fixed in TurboVNC 3.0.) >> >> 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.) >> >> On 2/10/21 8:15 AM, Dieter Blaas wrote: >>> >>> Hi, >>> >>> 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..... >>> >>> I cannot pin down the reason for this behaviour and it occurs mostly >>> after updating, upgrading, reboot etc. I would be extremely thankful >>> for hints. >>> >>> Here just snippets of the log file when I start the server as normal >>> user under centos: >>> >>> ---------------- >>> >>> AUDIT: Wed Feb 10 00:58:11 2021: 1309 Xvnc: *client 2 rejected from >>> local host* >>> gnome-session[1335]: WARNING: *Could not make bus activated clients >>> aware of DISPLAY=:3 environment variable: Failed to connect to >>> socket /tmp/dbus-V4JphZTJqg: Connection refused* >>> gnome-session[1335]: WARNING: *Could not make bus activated clients >>> aware of GNOME_DESKTOP_SESSION_ID=this-is-deprecated environment >>> variable: Failed to connect to socket */tmp/dbus-V4JphZTJqg: >>> *Connection refused* >>> gnome-session[1335]: WARNING: Could not make bus activated clients >>> aware of >>> SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/1335,unix/unix:/tmp/.ICE-unix/1335 >>> environment variable: Failed to connect to socket >>> /tmp/dbus-V4JphZTJqg: Connection refused >>> XIO: fatal IO error 11 (Resource temporarily unavailable) on >>> >>> --------------- >>> >>> And when I start is as root: >>> >>> Connections: accepted: xxx.xxx.xxx.xxx::40779 >>> SConnection: Client needs protocol version 3.8 >>> SConnection: Client requests security type VncAuth(2) >>> VNCSConnST: Server default pixel format depth 24 (32bpp) >>> little-endian rgb888 >>> VNCSConnST: Client pixel format depth 24 (32bpp) little-endian rgb888 >>> ------------------ >>> >>> Thanks for help, best, Dieter >>> >>> ------------------------------------------------------------------------ >>> Dieter Blaas, >>> Max Perutz Laboratories >>> Medical University of Vienna, >>> Inst. Med. Biochem., Vienna Biocenter (VBC), >>> Dr. Bohr Gasse 9/3, >>> A-1030 Vienna, Austria, >>> Tel: 0043 1 4277 61630, >>> Mobile: 0043 699 1942 1659 >>> e-mail: [email protected] >>> ------------------------------------------------------------------------ >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "TurboVNC User Discussion/Support" group. >>> To unsubscribe from this group and stop receiving emails from it, >>> send an email to [email protected] >>> <mailto:[email protected]>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/turbovnc-users/1c020406-e17c-f248-2550-0fbc03ec0a28%40meduniwien.ac.at >>> <https://groups.google.com/d/msgid/turbovnc-users/1c020406-e17c-f248-2550-0fbc03ec0a28%40meduniwien.ac.at?utm_medium=email&utm_source=footer>. >> -- >> You received this message because you are subscribed to the Google >> Groups "TurboVNC User Discussion/Support" group. >> To unsubscribe from this group and stop receiving emails from it, >> send an email to [email protected] >> <mailto:[email protected]>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/turbovnc-users/3f3788ec-d907-f9bf-de19-b35f5c720987%40virtualgl.org >> <https://groups.google.com/d/msgid/turbovnc-users/3f3788ec-d907-f9bf-de19-b35f5c720987%40virtualgl.org?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/308d26da-cef5-49b1-030e-05f58c376a3f%40virtualgl.org.
