Hi DRC,
for me this issue is resolved in the meanwhile. I managed the relevant
files on the remote host to start TuboVNC's X Server for display :2 and
therefore with port 5902. And for both TuboVNC viewers (on the remote
host too and on my Windows PC at home) I did the same. That works
perfectly. So I wouldn't need an improvement regarding this.
And no, I don't use VirtualGL. The remote host is my workstation (owned
by my employer), where I do my daily work. For my job I have no need to
use OpenGL (or VirtualGL).
But I have some other new issues with TuboVNC, which I will report in
the next days (when I have some time to write the mail(s)).
BR
transgar
Am 02.01.2024 um 20:45 schrieb 'DRC' via TurboVNC User Discussion/Support:
Further information regarding this issue:
With the default GDM configuration, there is no X server active on the
login screen, because the GDM greeter is using Wayland. When you log
in, either Xwayland or Xorg (depending on whether you chose a Wayland
or an Xorg session) is started on Display :0, so there is no
possibility of a conflict with TurboVNC. However, if you use
vglserver_config in VirtualGL to configure the host for use with
VirtualGL's GLX back end, vglserver_config will disable Wayland in
GDM. That causes the GDM greeter to use Xorg rather than Wayland, and
the greeter's Xorg instance listens on Display :0. Thus, VirtualGL
can use the greeter's X server to access the GPU while the host is
sitting at the login prompt.
On hosts configured thusly (with WaylandEnable=false in GDM's
custom.conf file), a conflict occurs if you start a TurboVNC session
while the host is sitting at the login prompt, then you log in
locally. When you start a TurboVNC session while the host is sitting
at the login prompt, TurboVNC (rightfully) chooses Display :1 for the
session, because nothing is using the resources associated with
Display :1. However, if you then log in locally, GDM starts a second
Xorg instance for the local session (so as not to conflict with the
greeter's Xorg instance.) GDM indiscriminately chooses Display :1 for
the local session without checking whether something else is already
using the resources associated with Display :1. Thus, it effectively
stomps all over the TurboVNC session that is listening on Display :1.
That causes the problems that you observed.
I can (and will) make the vncserver script more robust, in the sense
that it will check whether an abstract socket for a display number is
in use before deciding to use that display number. However, GDM needs
to do likewise.
The only apparent workarounds for this are:
1. If you have used vglserver_config to configure a host for use with
VirtualGL's GLX back end, then be very cautious when logging in
locally. That is true irrespective of TurboVNC, because logging in
locally on such a host will cause GDM to suspend the greeter's X
server, which has the effect of causing any applications currently
running with VirtualGL to freeze. Use '/opt/TurboVNC/bin/vncserver
-list' to ensure that no TurboVNC sessions are listening on :1 before
you log in locally, and avoid local logins if at all possible.
2. Comment out 'WaylandEnable=false' in /etc/gdm3/custom.conf, and
restart GDM. This is not true of all modern Linux systems, but with
Ubuntu 22 at least, GDM will continue to start an Xorg instance at the
login prompt even though the greeter is using Wayland. You can set
VGL_DISPLAY=:1024 to use that Xorg instance as a 3D X server with
VirtualGL's GLX back end.
I'm also going to investigate whether it might be possible for
VirtualGL to play more nicely with Wayland on modern Linux distributions.
On Tuesday, December 19, 2023 at 1:40:38 PM UTC-5 DRC wrote:
No, by deleting /tmp/.X11-unix/X1, I was able to exactly reproduce
the
issue you reported with the Session Manager. That error occurred
when
the Session Manager tried to start a new TurboVNC session through
SSH.
In order for Port=5901 to have any effect, it would either have to be
specified in the default TurboVNC connection info file
(~/.vnc/default.turbovnc), or it would have to be specified in
another
connection info file (either a TightVNC-compatible connection info
file,
which has a .vnc extension, or a TurboVNC connection info file, which
has a .turbovnc extension) that you pass to the TurboVNC Viewer on
the
command line. Otherwise, the mere existence of such a connection
info
file on the machine wouldn't matter. Also, the error occurred
prior to
the TurboVNC Viewer attempting to establish the RFB connection
with the
TurboVNC Server, so the viewer had not yet used the value of the Port
parameter.
DRC
On 12/19/23 12:40 PM, Torsten Kupke wrote:
> Hi CRC,
>
> Am 19.12.2023 um 16:41 schrieb 'DRC' via TurboVNC User
> Discussion/Support:
>> Apparently something happened that caused /tmp/.X11-unix/X1 to be
>> deleted, so the vncserver script didn't know that the primary X
>> server was using Display :1, and it tried to use that display
number
>> itself.
>
> Maybe I have another explantion for this: I have a .vnc file
stored on
> that machine specifying "port=5901". I think, the viewer found this
> file and therefore tried to connect to the XServer :1. Could
this be
> the case? So if :1 now is in use by the native XServer, I simply
would
> have to specify "port=5902" in my .vnc file. Can you agree?
Would this
> solve my issue?
>
> However, I'm on Christmas vacation now. So I will need a proper
> solution not before 2nd of Jan. '24.
>
> Merry Christmas and a happy new year for you and all other readers!
>
> tkansgar
>
--
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/2e98ca31-b6d8-4971-bc59-1f1edf5f508en%40googlegroups.com
<https://groups.google.com/d/msgid/turbovnc-users/2e98ca31-b6d8-4971-bc59-1f1edf5f508en%40googlegroups.com?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/0a67d17c-9453-4b4e-841e-f9598acee91b%40t-online.de.
