No clue what's happening with your CentOS 6 machine. CentOS 6 was 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. On 2/23/21 2:57 PM, Dieter Blaas wrote: > Thank you very much for looking into this! Definitely, the laptop with > 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 > > on the Centos machine without avail. > > ------------------------------------------------------------------------ > 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.bl...@meduniwien.ac.at > ------------------------------------------------------------------------ > > On 23.02.2021 21:07, DRC wrote: >> Thanks for letting me access your machine for testing. I first >> 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. >> >> On 2/19/21 12:03 AM, Dieter Blaas wrote: >>> Hi, >>> >>> 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 >>> >>> Creating default startup script /home/blaas/.vnc/xstartup.turbovnc >>> Starting applications specified in /home/blaas/.vnc/xstartup.turbovnc >>> Log file is /home/blaas/.vnc/ubuntu:1.log >>> ------------------------------------------------------------------------------------------ >>> >>> >>> blaas@ubuntu:~/.vnc$ /opt/TurboVNC/bin/vncserver -verbose -wm >>> mate-session >>> 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 >>> >>> 19/02/2021 06:23:43 Using security configuration file >>> /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: 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 >>> mate-session-check-accelerated: GL Helper exited with code 512 >>> mate-session-check-accelerated: GLES Helper exited with code 512 >>> SSH_AUTH_SOCK=/run/user/1000/keyring/ssh >>> 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. >>> --------------------------------------------------------------------- >>> >>> >>> >>> >>> >>> On 2021-02-18 21:47, DRC wrote: >>>> OK, and what does the log say if you do exactly the same thing on the >>>> machine where MATE is working properly? I'm just trying to narrow down >>>> what the differences in those two systems might be. >>>> >>>> DRC >>>> >>>> On 2/18/21 12:03 PM, Dieter Blaas wrote: >>>>> Thanks! >>>>> >>>>> --------------------------------------------------------------------------------------------------------------- >>>>> >>>>> >>>>> >>>>> >>>>> (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 >>>>> >>>>> 18/02/2021 19:00:08 Using security configuration file >>>>> /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: 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 >>>>> >>>>> ** (mate-session:4043): WARNING **: 19:00:09.545: Unable to connect to >>>>> dbus: Could not connect: Connection refused >>>>> >>>>> ** (mate-session-check-accelerated:4073): WARNING **: 19:00:09.598: >>>>> Unable to connect to dbus: Could not connect: Connection refused >>>>> mate-session-check-accelerated: GL Helper exited with code 512 >>>>> >>>>> ** (mate-session-check-accelerated-gles-helper:4098): WARNING **: >>>>> 19:00:09.760: Unable to connect to dbus: Could not connect: Connection >>>>> refused >>>>> mate-session-check-accelerated: GLES Helper exited with code 512 >>>>> mate-session[4043]: WARNING: Could not make bus activated clients >>>>> aware of DISPLAY=:1 environment variable: Could not connect: >>>>> Connection refused >>>>> mate-session[4043]: WARNING: Could not make bus activated clients >>>>> aware of MATE_DESKTOP_SESSION_ID=this-is-deprecated environment >>>>> variable: Could not connect: Connection refused >>>>> >>>>> (mate-session:4043): dconf-WARNING **: 19:00:09.833: failed to commit >>>>> changes to dconf: Could not connect: Connection refused >>>>> mate-session[4043]: WARNING: Could not make bus activated clients >>>>> aware 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.bl...@meduniwien.ac.at >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> On 18.02.2021 18:29, DRC wrote: >>>>>> Please try >>>>>> >>>>>> /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. >>>>>> >>>>>> >>>>>> On 2/18/21 11:11 AM, Dieter Blaas wrote: >>>>>>> no error message here: >>>>>>> >>>>>>> (base) blaas@ubuntu:/opt/TurboVNC/bin$ vncserver -verbose >>>>>>> >>>>>>> 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 >>>>>>> ------------------------------------------------------------------------------- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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.bl...@meduniwien.ac.at >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 18.02.2021 17:46, DRC wrote: >>>>>>>> Try passing -verbose to /opt/TurboVNC/bin/vncserver and see if it >>>>>>>> prints >>>>>>>> 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. >>>>>>>> >>>>>>>> On 2/18/21 12:10 AM, Dieter Blaas wrote: >>>>>>>>> Sorry, I thought that I already answered. Here is the result: >>>>>>>>> >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> The semicolon is there! >>>>>>>>>> /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. >>>>>>>>> $ /opt/TurboVNC/bin/vncserver -noxstartup >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> mate-session-check-accelerated: GL Helper exited with code 512 >>>>>>>>> mate-session-check-accelerated: GLES Helper exited with code 512 >>>>>>>>> mate-session[7670]: WARNING: Failed to acquire >>>>>>>>> org.gnome.SessionManager >>>>>>>>>> $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 >>>>>>>>> Thanks, Dieter >>>>>>>>>> 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! >>>>>>>>>>> >>>>>>>>>>> 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.bl...@meduniwien.ac.at >>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 12.02.2021 18:12, DRC wrote: >>>>>>>>>>> >>>>>>>>>>>> On 2/11/21 11:11 PM, Dieter Blaas wrote: >>>>>>>>>>>>> *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. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 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.bl...@meduniwien.ac.at >>>>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 11.02.2021 20:21, DRC wrote: >>>>>>>>>>>>>> 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: dieter.bl...@meduniwien.ac.at >>>>>>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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: dieter.bl...@meduniwien.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-users+unsubscr...@googlegroups.com >>>>>>>>>>>>>>>>> <mailto:turbovnc-users+unsubscr...@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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <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 >>>>>>>>>>>>>>>> turbovnc-users+unsubscr...@googlegroups.com >>>>>>>>>>>>>>>> <mailto:turbovnc-users+unsubscr...@googlegroups.com>. >>>>>>>>>>>>>>>> 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 turbovnc-users+unsubscr...@googlegroups.com >>>>>>>>>>>>>> <mailto:turbovnc-users+unsubscr...@googlegroups.com>. >>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>> https://groups.google.com/d/msgid/turbovnc-users/308d26da-cef5-49b1-030e-05f58c376a3f%40virtualgl.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> <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-users+unsubscr...@googlegroups.com >>>>>>>>>>>>> <mailto:turbovnc-users+unsubscr...@googlegroups.com>. >>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>> https://groups.google.com/d/msgid/turbovnc-users/1430d141-1cb0-23c7-552c-3fa7b1b521ab%40meduniwien.ac.at >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> <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-users+unsubscr...@googlegroups.com >>>>>>>>>>>> <mailto:turbovnc-users+unsubscr...@googlegroups.com>. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/d/msgid/turbovnc-users/c7585861-e735-a27a-f102-7e7204da448f%40virtualgl.org >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> <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-users+unsubscr...@googlegroups.com >>>>>>>>>>> <mailto:turbovnc-users+unsubscr...@googlegroups.com>. >>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>> https://groups.google.com/d/msgid/turbovnc-users/4fbe41f4-ba10-bdc2-f608-0eff711d755f%40meduniwien.ac.at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> <https://groups.google.com/d/msgid/turbovnc-users/4fbe41f4-ba10-bdc2-f608-0eff711d755f%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-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/c3e50044-9a18-a90c-9e96-27e68c1e2e60%40virtualgl.org.
