I don't know why the issue occurred in the first place, then, unless for
some reason your employer also disabled Wayland in
/etc/gdm3/custom.conf. Regardless, I'm glad you were able to find a
workaround for your particular use case. I did notice that, on my Rocky
Linux 8 box, the greeter always starts Xorg on Display :0 regardless of
the value of WaylandEnable. Maybe Ubuntu 22 can behave that way as
well, under certain circumstances.
On 1/2/24 3:16 PM, Torsten Kupke wrote:
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 turbovnc-users+unsubscr...@googlegroups.com.
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 turbovnc-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/0a67d17c-9453-4b4e-841e-f9598acee91b%40t-online.de
<https://groups.google.com/d/msgid/turbovnc-users/0a67d17c-9453-4b4e-841e-f9598acee91b%40t-online.de?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/a3f470b0-9cb9-ee22-1270-aaf4abb58ae8%40virtualgl.org.
