Oof. Apparently I already filed the issue as a bug against RHEL, and
Red Hat rejected it.
https://bugzilla.redhat.com/show_bug.cgi?id=1673793
But since the issue also occurs in Ubuntu, maybe I should've filed it
against GDM.
(I realize that the issue is resolved from your POV. I am just updating
this thread in case someone finds it via Google. Apparently I answer so
many bug reports that I can't remember the ones I myself filed two years
ago, so the person who finds this thread via Google may be me.)
On 1/2/24 6:29 PM, DRC wrote:
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/350b04cd-a40d-662c-3bfa-8ef213ee34b2%40virtualgl.org.
