grey screen on VNC
Dieter Blaas
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: dieter...@meduniwien.ac.at ------------------------------------------------------------------------
DRC
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
~/.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.)
--
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 turbovnc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/1c020406-e17c-f248-2550-0fbc03ec0a28%40meduniwien.ac.at.
Dieter Blaas
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) 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....
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: dieter...@meduniwien.ac.at ------------------------------------------------------------------------
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.)
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/3f3788ec-d907-f9bf-de19-b35f5c720987%40virtualgl.org.
DRC
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!".
Dieter Blaas
Hi,
1) Centos-6.10:
following this: https://turbovnc.org/Downloads/YUM
I get, regardless of whether I try installing from the repository or from the downloaded file "VirtualGL-2.6.5.x86_64.rpm":
sudo yum install turbovnc
Loaded plugins: etckeeper, fastestmirror, nvidia, priorities,
refresh-packagekit, security
Setting up Install Process
Determining fastest mirrors
YumRepo Error: All mirror URLs are not using ftp, http[s] or
file.
Eg. Invalid release/repo/arch combination/
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
Eg. Invalid release/repo/arch combination/
removing mirrorlist with no valid mirrors:
/var/cache/yum/x86_64/6/centos-sclo-rh/mirrorlist.txt
Error: Cannot find a valid baseurl for repo: centos-sclo-rh
(base) [blaasd3@blaaslinpc:0 Downloads]$
googling I found that this error results from centos-6.10 EOL - it gets directed to a not-any-more-existing repository
Probably I would need compiling it myself...
2) I edited turbovnc.conf to contain the line '$wm = "mate-session";' in BOTH laptops.
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!
snippet from the log file on the Lenovo W520:
12/02/2021 06:05:22 Maximum clipboard transfer size: 1048576
bytes
12/02/2021 06:05:22 VNC extension running!
** (mate-session:2795): WARNING **: 06:05:23.448: Unable to
connect to dbus: Could not connect: Connection refused
** (mate-session-check-accelerated:2825): WARNING **:
06:05:23.499: Unable to connect to dbus: Could not connect: Conne
ction refused
mate-session-check-accelerated: GL Helper exited with code 512
** (mate-session-check-accelerated-gles-helper:2850): WARNING **:
06:05:23.591: Unable to connect to dbus: Could not co
nnect: Connection refused
mate-session-check-accelerated: GLES Helper exited with code 512
mate-session[2795]: WARNING: Could not make bus activated clients
aware of DISPLAY=:1 environment variable: Could not c
onnect: Connection refused
mate-session[2795]: WARNING: Could not make bus activated clients
aware of MATE_DESKTOP_SESSION_ID=this-is-deprecated e
nvironment variable: Could not connect: Connection refused
(mate-session:2795): dconf-WARNING **: 06:05:23.662: failed to
commit changes to dconf: Could not connect: Connection r
efused
Thanks for hints, 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: dieter...@meduniwien.ac.at ------------------------------------------------------------------------
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/308d26da-cef5-49b1-030e-05f58c376a3f%40virtualgl.org.
DRC
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
Eg. Invalid release/repo/arch combination/
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
Eg. Invalid release/repo/arch combination/
removing mirrorlist with no valid mirrors: /var/cache/yum/x86_64/6/centos-sclo-rh/mirrorlist.txt
Error: Cannot find a valid baseurl for repo: centos-sclo-rh
(base) [blaasd3@blaaslinpc:0 Downloads]$googling I found that this error results from centos-6.10 EOL - it gets directed to a not-any-more-existing repository
Probably I would need compiling it myself...
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.
2) I edited turbovnc.conf to contain the line '$wm = "mate-session";' in BOTH laptops.
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 clue, sorry. I'm assuming that you removed ~/.vnc/xstartup.turbovnc on both machines prior to starting the TurboVNC Server. As a sanity check, try passing
-wm mate-session
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/1430d141-1cb0-23c7-552c-3fa7b1b521ab%40meduniwien.ac.at.
Dieter Blaas
Thanks for the hints!
1) I shall try to solve the Centos problem following your advice in the next days!
2) I checked turbovncserver.conf and the entry "'$wm =
"mate-session" is there. When replacing it with "$wm = "2d"
as of
## Java TurboVNC Viewer) or 0 to disable
## $wm -- the window manager startup script to use
(for instance,
## "mate-session" or "2d")
##
I get the same black screen but this time NO ERROR MESSAGE!
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: dieter...@meduniwien.ac.at ------------------------------------------------------------------------
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/c7585861-e735-a27a-f102-7e7204da448f%40virtualgl.org.
DRC
that's not the issue, then try running
/opt/TurboVNC/bin/vncserver -noxstartup
DISPLAY=:{n} mate-session
(where {n} is the TurboVNC session's display number)
and see if mate-session prints any errors.
$wm = "2d" will enable the "fallback" or "flashback" window manager on
RHEL/CentOS or Ubuntu, which is basically just GNOME 3 with a look &
feel that is more similar to GNOME 2. That isn't the same as MATE.
(MATE literally is GNOME 2, or rather, a fork of it.)
DRC
On 2/16/21 10:18 AM, Dieter Blaas wrote:
> Thanks for the hints!
>
> 1) I shall try to solve the Centos problem following your advice in the
> next days!
>
>
> ## Java TurboVNC Viewer) or 0 to disable
> instance,**
> **## "mate-session" or "2d")**
> **##*
> I get the same black screen but this time NO ERROR MESSAGE!
>
> 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: dieter...@meduniwien.ac.at
> ------------------------------------------------------------------------
>
> On 12.02.2021 18:12, DRC wrote:
>
>> On 2/11/21 11:11 PM, Dieter Blaas wrote:
>>>
>>> *** Eg. Invalid release/repo/arch combination/*
>>> Eg. Invalid release/repo/arch combination/
>>> removing mirrorlist with no valid mirrors:
>>> /var/cache/yum/x86_64/6/centos-sclo-rh/mirrorlist.txt
>>>
>>> gets directed to a not-any-more-existing repository*
>>> Probably I would need compiling it myself...
>>>
>> 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.
>>
>>
>>> "mate-session";' in BOTH laptops._
>>>>>>> from local host*
>>>>>>> gnome-session[1335]: WARNING: *Could not make bus activated
>>>>>>> gnome-session[1335]: WARNING: *Could not make bus activated
>>>>>>> environment variable: Failed to connect to socket
>>>>>>> https://groups.google.com/d/msgid/turbovnc-users/1c020406-e17c-f248-2550-0fbc03ec0a28%40meduniwien.ac.at
>>>>>> 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 turbovnc-user...@googlegroups.com
>>>>>> <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 turbovnc-user...@googlegroups.com
>>>> <https://groups.google.com/d/msgid/turbovnc-users/308d26da-cef5-49b1-030e-05f58c376a3f%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 turbovnc-user...@googlegroups.com
>>> <https://groups.google.com/d/msgid/turbovnc-users/1430d141-1cb0-23c7-552c-3fa7b1b521ab%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 turbovnc-user...@googlegroups.com
>> <https://groups.google.com/d/msgid/turbovnc-users/c7585861-e735-a27a-f102-7e7204da448f%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 turbovnc-user...@googlegroups.com
> <https://groups.google.com/d/msgid/turbovnc-users/4fbe41f4-ba10-bdc2-f608-0eff711d755f%40meduniwien.ac.at?utm_medium=email&utm_source=footer>.
Dieter Blaas
On 16.02.2021 21:40, DRC wrote:
> Just to confirm, $wm = "mate-session" is followed by a semicolon? If
> that's not the issue, then try running
> DISPLAY=:{n} mate-session
> (where {n} is the TurboVNC session's display number)
>
> and see if mate-session prints any errors.
Desktop 'TurboVNC: ubuntu:1 (blaas)' started on display ubuntu:1
Log file is /home/blaas/.vnc/ubuntu:1.log
(base) blaas@ubuntu:~$ DISPLAY=:1 mate-session
> $wm = "2d" will enable the "fallback" or "flashback" window manager on
> RHEL/CentOS or Ubuntu, which is basically just GNOME 3 with a look &
> feel that is more similar to GNOME 2. That isn't the same as MATE.
> (MATE literally is GNOME 2, or rather, a fork of it.)
>
> DRC
DRC
any OpenGL errors in the server log. This issue could be due to the
system not having the Mesa DRI drivers installed. If the software
OpenGL implementation in the TurboVNC Server fails to initialize for any
reason, then the server won't have a GLX extension, which can cause
window managers to fail in the manner described below.
Dieter Blaas
(base) blaas@ubuntu:/opt/TurboVNC/bin$ vncserver -verbose
Desktop 'TurboVNC: ubuntu:1 (blaas)' started on display ubuntu:1
This is ubuntu:1.log:
base) blaas@ubuntu:~/.vnc$ cat ubuntu:1.log
TurboVNC Server (Xvnc) 64-bit v2.2.5 (build 20200507)
Copyright (C) 1999-2020 The VirtualGL Project and many others (see
README.txt)
Visit http://www.TurboVNC.org for more information on TurboVNC
18/02/2021 18:08:00 Using security configuration file
/etc/turbovncserver-security.conf
18/02/2021 18:08:00 Enabled security type 'tlsvnc'
18/02/2021 18:08:00 Enabled security type 'tlsotp'
18/02/2021 18:08:00 Enabled security type 'tlsplain'
18/02/2021 18:08:00 Enabled security type 'x509vnc'
18/02/2021 18:08:00 Enabled security type 'x509otp'
18/02/2021 18:08:00 Enabled security type 'x509plain'
18/02/2021 18:08:00 Enabled security type 'vnc'
18/02/2021 18:08:00 Enabled security type 'otp'
18/02/2021 18:08:00 Enabled security type 'unixlogin'
18/02/2021 18:08:00 Enabled security type 'plain'
18/02/2021 18:08:00 Desktop name 'TurboVNC: ubuntu:1 (blaas)' (ubuntu:1)
18/02/2021 18:08:00 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t
18/02/2021 18:08:00 Listening for VNC connections on TCP port 5901
18/02/2021 18:08:00 Interface 0.0.0.0
18/02/2021 18:08:00 Listening for HTTP connections on TCP port 5801
18/02/2021 18:08:00 URL http://ubuntu:5801
18/02/2021 18:08:00 Interface 0.0.0.0
18/02/2021 18:08:00 Framebuffer: BGRX 8/8/8/8
18/02/2021 18:08:00 New desktop size: 1240 x 900
18/02/2021 18:08:00 New screen layout:
18/02/2021 18:08:00 0x00000040 (output 0x00000040): 1240x900+0+0
18/02/2021 18:08:00 Maximum clipboard transfer size: 1048576 bytes
18/02/2021 18:08:00 VNC extension running!
(II) IGLX: enabled GLX_MESA_copy_sub_buffer
(II) IGLX: Loaded and initialized swrast
(II) GLX: Initialized DRISWRAST GL provider for screen 0
(II) XKB: Reusing cached keymap
(II) XKB: Reusing cached keymap
No window manager startup script found. Use the TVNC_WM environment
variable to specify the path to a window manager startup script or
executable. Falling back to TWM.
TWM not found. I give up.
----------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------
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: dieter...@meduniwien.ac.at
------------------------------------------------------------------------
DRC
/opt/TurboVNC/bin/vncserver -verbose -wm mate-session
so I can be sure that the mate-session error is indeed occurring in a
server instance with a working OpenGL implementation.
Dieter Blaas
---------------------------------------------------------------------------------------------------------------
(base) blaas@ubuntu:~/.vnc$ /opt/TurboVNC/bin/vncserver -verbose -wm
mate-session
Desktop 'TurboVNC: ubuntu:1 (blaas)' started on display ubuntu:1
Starting applications specified in /home/blaas/.vnc/xstartup.turbovnc
Log file is /home/blaas/.vnc/ubuntu:1.log
TurboVNC Server (Xvnc) 64-bit v2.2.5 (build 20200507)
Copyright (C) 1999-2020 The VirtualGL Project and many others (see
README.txt)
Visit http://www.TurboVNC.org for more information on TurboVNC
/etc/turbovncserver-security.conf
18/02/2021 19:00:08 Enabled security type 'tlsvnc'
18/02/2021 19:00:08 Enabled security type 'tlsotp'
18/02/2021 19:00:08 Enabled security type 'tlsplain'
18/02/2021 19:00:08 Enabled security type 'x509vnc'
18/02/2021 19:00:08 Enabled security type 'x509otp'
18/02/2021 19:00:08 Enabled security type 'x509plain'
18/02/2021 19:00:08 Enabled security type 'vnc'
18/02/2021 19:00:08 Enabled security type 'otp'
18/02/2021 19:00:08 Enabled security type 'unixlogin'
18/02/2021 19:00:08 Enabled security type 'plain'
18/02/2021 19:00:08 Desktop name 'TurboVNC: ubuntu:1 (blaas)' (ubuntu:1)
18/02/2021 19:00:08 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t
18/02/2021 19:00:08 Listening for VNC connections on TCP port 5901
18/02/2021 19:00:08 Interface 0.0.0.0
18/02/2021 19:00:08 Listening for HTTP connections on TCP port 5801
18/02/2021 19:00:08 URL http://ubuntu:5801
18/02/2021 19:00:08 Interface 0.0.0.0
18/02/2021 19:00:08 Framebuffer: BGRX 8/8/8/8
18/02/2021 19:00:08 New desktop size: 1240 x 900
18/02/2021 19:00:08 New screen layout:
18/02/2021 19:00:08 0x00000040 (output 0x00000040): 1240x900+0+0
18/02/2021 19:00:08 Maximum clipboard transfer size: 1048576 bytes
18/02/2021 19:00:08 VNC extension running!
(II) IGLX: Loaded and initialized swrast
(II) GLX: Initialized DRISWRAST GL provider for screen 0
(II) XKB: Reusing cached keymap
(II) XKB: Reusing cached keymap
19:00:09.760: Unable to connect to dbus: Could not connect: Connection
refused
of MATE_DESKTOP_SESSION_ID=this-is-deprecated environment variable:
of
SESSION_MANAGER=local/ubuntu:@/tmp/.ICE-unix/4043,unix/ubuntu:/tmp/.ICE-unix/4043
environment variable: Could not connect: Connection refused
mate-session[4043]: GLib-GIO-CRITICAL:
g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION
(connection)' failed
mate-session[4043]: GLib-GIO-CRITICAL:
g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION
(connection)' failed
mate-session[4043]: GLib-GIO-CRITICAL:
g_dbus_connection_get_unique_name: assertion 'G_IS_DBUS_CONNECTION
(connection)' failed
------------------------------------------------------------------------
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: dieter...@meduniwien.ac.at
------------------------------------------------------------------------
DRC
machine where MATE is working properly? I'm just trying to narrow down
what the differences in those two systems might be.
DRC
Dieter Blaas
This is the one that works:
-----------------------------------------------------------------------------------------
blaas@ubuntu:~/.vnc$ /opt/TurboVNC/bin/vncserver -verbose -wm mate-session
Desktop 'TurboVNC: ubuntu:1 (blaas)' started on display ubuntu:1
Log file is /home/blaas/.vnc/ubuntu:1.log
------------------------------------------------------------------------------------------
Copyright (C) 1999-2020 The VirtualGL Project and many others (see
README.txt)
Visit http://www.TurboVNC.org for more information on TurboVNC
/etc/turbovncserver-security.conf
19/02/2021 06:23:43 Enabled security type 'tlsvnc'
19/02/2021 06:23:43 Enabled security type 'tlsotp'
19/02/2021 06:23:43 Enabled security type 'tlsplain'
19/02/2021 06:23:43 Enabled security type 'x509vnc'
19/02/2021 06:23:43 Enabled security type 'x509otp'
19/02/2021 06:23:43 Enabled security type 'x509plain'
19/02/2021 06:23:43 Enabled security type 'vnc'
19/02/2021 06:23:43 Enabled security type 'otp'
19/02/2021 06:23:43 Enabled security type 'unixlogin'
19/02/2021 06:23:43 Enabled security type 'plain'
19/02/2021 06:23:43 Desktop name 'TurboVNC: ubuntu:1 (blaas)' (ubuntu:1)
19/02/2021 06:23:43 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t
19/02/2021 06:23:43 Listening for VNC connections on TCP port 5901
19/02/2021 06:23:43 Interface 0.0.0.0
19/02/2021 06:23:43 Listening for HTTP connections on TCP port 5801
19/02/2021 06:23:43 URL http://ubuntu:5801
19/02/2021 06:23:43 Interface 0.0.0.0
19/02/2021 06:23:43 Framebuffer: BGRX 8/8/8/8
19/02/2021 06:23:43 New desktop size: 1240 x 900
19/02/2021 06:23:43 New screen layout:
19/02/2021 06:23:43 0x00000040 (output 0x00000040): 1240x900+0+0
19/02/2021 06:23:43 Maximum clipboard transfer size: 1048576 bytes
19/02/2021 06:23:43 VNC extension running!
(II) IGLX: Loaded and initialized swrast
(II) GLX: Initialized DRISWRAST GL provider for screen 0
(II) XKB: Reusing cached keymap
(II) XKB: Reusing cached keymap
mate-session-check-accelerated: GLES Helper exited with code 512
mate-session[2831]: WARNING: Unable to find provider '' of required
component 'dock'
Window manager warning: Log level 128: unsetenv() is not thread-safe and
should not be used after threads are created
Window manager warning: Log level 128: Name
com.canonical.AppMenu.Registrar does not exist on the session bus
unable to find device 11
mate-session[2831]: WARNING: Could not launch application
'hplip-systray.desktop': Unable to start application: Failed to execute
child process “hp-systray†(No such file or directory)
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
Failure: Module initialisation failed
(process:3032): indicator-sound-WARNING **: 06:23:49.072:
volume-control-pulse.vala:735: unable to get pulse unix socket:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.PulseAudio1 was not provided by any .service files
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
** (process:3078): WARNING **: 06:23:49.538: could not find the desktop
file for 'org.gnome.Calendar.desktop'
caja-dropbox is not installed, doing nothing.
(process:3078): Indicator-Datetime-WARNING **: 06:23:49.600:
Unrecognized TZID: 'Etc/Utc'
(process:3078): Indicator-Datetime-WARNING **: 06:23:49.601:
Unrecognized TZID: 'Etc/Utc'
(process:3078): Indicator-Datetime-WARNING **: 06:23:49.753:
Unrecognized TZID: 'Etc/Utc'
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
unable to find device FTSC1000:00 2808:1015
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 141 (RANDR)
Minor opcode of failed request: 2 (RRSetScreenConfig)
Serial number of failed request: 14
Current serial number in output stream: 14
(caja:2985): Gtk-WARNING **: 06:23:50.356: Failed to register client:
GDBus.Error:org.gnome.SessionManager.AlreadyRegistered: Unable to
register client
Initializing caja-open-terminal extension
** (update-notifier:3153): WARNING **: 06:23:51.520: already running?
no maximize: true
** (polkit-mate-authentication-agent-1:3062): WARNING **: 06:23:51.629:
Unable to register authentication agent:
GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication
agent already exists for the given subject
Cannot register authentication agent:
GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication
agent already exists for the given subject
** (mate-screensaver:3111): WARNING **: 06:23:51.654: screensaver
already running in this session
(nm-applet:3122): nm-applet-WARNING **: 06:23:51.743: An agent with this
ID is already registered for this user.
mate-optimus-applet: launched.
- nvidia-settings and prime-select not detected.
mate-optimus-applet: NVIDIA Optimus is not supported.
blueman-applet version 2.1.2 starting
There is an instance already running
[Debug] Autostart mode enabled.
[Welcome] Welcome was autostarted but autostart is disabled.
RuntimeError: object at 0x7fa599f881c0 of type FolderColorMenu is not
initialized
RuntimeError: object at 0x7fa599f1da80 of type RenameMenu is not initialized
INFO:root:The HUD is disabled via org.mate.hud in gsettings.
---------------------------------------------------------------------
Dr. Dieter Blaas
Max F. Perutz Laboratories,
Inst. Med. Biochem.,
Med. Univ. Vienna
Dr. Bohr Gasse 9/3
A-1030 Vienna, Austria
Tel. 0043 1 4277 61630
Fax 0043 1 4277 9616
Dieter Blaas
I just tried the brand new TurboVNC version you just made
available. I get the same black screen as the previous version when
connecting to this particular machine!
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: dieter...@meduniwien.ac.at
------------------------------------------------------------------------
DRC
points in a tech support discussion. That comes across as yelling. I
can't wave a magic wand and fix an issue that I have thus far been
unable to reproduce. TurboVNC was long overdue for a release, and since
I could not readily reproduce this issue, I had no choice but to put out
the release. It is not surprising that you still experience the issue,
since nothing in 2.2.6 specifically fixed it.
Looking at the logs, the issue appears to be DBus-related somehow. In
"I'm assuming that you removed ~/.vnc/xstartup.turbovnc on both machines
prior to starting the TurboVNC Server."
MATE is working properly, so I'll ask again for confirmation that you
tried that on the other machine as well. If you can grant me access to
your machine via SSH, I can log in and diagnose the issue for you. It
would be quicker to do that than to go back and forth via e-mail like
this. Please e-mail me off-list if you would like to pursue that.
DRC
reconciled some possibly relevant differences in the installed packages
between your machine and mine in order to rule that out as a cause.
Making the packages on my machine match the packages on your machine
didn't have any effect. I was still unable to reproduce the failure
except on your machine.
I discovered that I could make the issue go away by passing -debug or
-fg to /opt/TurboVNC/bin/vncserver. When I attempted to manually
simulate the effect of -fg vs. no -fg, I wasn't able to reproduce the
issue. The issue could only be reproduced by letting the vncserver
script launch mate-session from xstartup.turbovnc. That suggests that
the issue might have somehow been timing-related. However, I tried
increasing the delay between Xvnc starting up and the vncserver script
invoking xstartup.turbovnc, and that didn't make the issue go away.
I stumbled upon a possible workaround, which is to launch mate-session
using dbus-launch:
export TVNC_SSHAGENT="/usr/bin/dbus-launch --exit-with-x11"
/opt/TurboVNC/bin/vncserver
Normally, unsetting DBUS_SESSION_BUS_ADDRESS in ~/.vnc/xstartup.turbovnc
should produce the same effect, but for some reason, it doesn't in this
case. I'm beginning to wonder if the presence of the nVidia drivers is
the key difference. (My Ubuntu 20.04 machine is really a virtual
machine running in VMWare, so it uses Mesa with a VMWare back end.) If
so, then it may make sense to always invoke dbus-launch when launching
the window manager.
I will keep trying to reproduce the issue on my end.
Dieter Blaas
the problem has a nVidia GPU, the other one not.
However, I also have two (headless) workstations with 2 nVidia GPUs
each. One runs Ubuntu-20.04 and turbovnc works fine. The other one runs
Centos 6.10. On this one I am having the same problem with turbovnc as
on my laptop (turbovnc is an older version here). However when I start
turbovncserver as root it works. On my laptop this does not solve the
problem. I also tried
export TVNC_SSHAGENT="/usr/bin/dbus-launch --exit-with-x11"
/opt/TurboVNC/bin/vncserver
------------------------------------------------------------------------
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: dieter...@meduniwien.ac.at
------------------------------------------------------------------------
DRC
actively used in multiple large TurboVNC installations until it became
EOL, and no one ever reported any problems like this during the years in
which it was used. I personally used CentOS 6 on my primary development
machine, which has an nVidia GPU, until a couple of years ago. I still
have a CentOS 6 machine with an AMD GPU that I use for VirtualGL testing
(because the old AMD Catalyst drivers won't run on any newer O/S.) I've
never had any problems using GNOME 2 with TurboVNC on any of those machines.
Referring to our support policy:
https://turbovnc.org/Documentation/OSSupport
I no longer provide free support for CentOS 6, since it is no longer
receiving public updates. I still test that operating system, so it
*should* work, but if it doesn't, someone else will have to figure out
why or pay for my labor to figure that out. I do recommend that you
migrate to the vault.centos.org repository URLs so you can do a 'yum
update' and install the latest TurboVNC Server on that machine. Then
you should 'rm ~/.vnc/xstartup.turbovnc' and let the server re-create it.
Perhaps dbus-launch on CentOS 6 doesn't like --exit-with-x11. You might
try --exit-with-session instead.
Dieter Blaas
I just found out that vnc-connections work fine (to my laptop as
well as to the Centos machine) when I start the vncserver as root.
Apparently, there must be a permission problem.... This reminds me that,
on the working desktop (ubuntu-20.04), I saw a message - something with
'keyring' - upon connecting and I guess I entered my password. So, I am
only left with the problem that I also must connect as root.
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: dieter...@meduniwien.ac.at
------------------------------------------------------------------------
DRC
you on your laptop. It worked for me on literally the same machine.
What's different?
I have an action item to try setting up Ubuntu 20.04 on an
nVidia-equipped machine and test whether there are any issues, but other
than that, you're beyond the limits of community support at this point.
Dieter Blaas
lot for your effort....
------------------------------------------------------------------------
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: dieter...@meduniwien.ac.at
------------------------------------------------------------------------
Dieter Blaas
I finally found the reason for the problems with turbovncserver: I
have anaconda3 installed on the PCs/workstations that give a black/grey
screen on connecting to them. It does not seem to suffice to deactivate
conda, it is necessary to remove it from $PATH. I have no clue why
anaconda3 is interfering with turbovncserver! I got the hint from here:
https://unix.stackexchange.com/questions/469909/vncviewer-errorcould-not-connect-to-session-bus-failed-to-connect-to-socket-tm
I hope that helps people encountering black/grey screen issues. It would
be good to find out why this is so and how it can be avoided when
needing to have anaconda3 at hand!
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: dieter...@meduniwien.ac.at
------------------------------------------------------------------------
DRC
named anaconda3 in the Ubuntu 20.04 repository.
Dieter Blaas
I did not uninstall it but just removed the reference to it from the
path and deleted everything referring to it from .bashrc. There might be
a much better way of doing so and I shall have to find out as soon as I
need anaconda's functionality again...
------------------------------------------------------------------------
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: dieter...@meduniwien.ac.at
------------------------------------------------------------------------
DRC
the same name as system executables, and it puts its binary directory
ahead of all others in the PATH. That is *really* bad behavior, and I'm
surprised that this is the worst symptom you've seen from it. I would
strongly suggest taking Anaconda out of the PATH and adding it back in
only when needed. Otherwise, you're likely to encounter other
hard-to-diagnose issues unrelated to TurboVNC.
Another note:
The xstartup.turbovnc script in the TurboVNC 3.0 evolving code base now
runs dbus-launch automatically. This solved some other issues on Ubuntu
18.04+ that were unrelated to Anaconda. TurboVNC 2.2.x users can borrow
the file from:
https://raw.githubusercontent.com/TurboVNC/turbovnc/dev/unix/xstartup.turbovnc
and place it in ~/.vnc if they are having window manager trouble under
Ubuntu 18.04+.