For completeness, I discovered a workaround to the issue, which is passing '-listen local' to /opt/TurboVNC/bin/vncserver. Apparently GDM will not stomp on Display :1 if TurboVNC is listening on both the abstract and pathname Unix domain sockets associated with that display. Passing '-listen local' causes TurboVNC to listen on the abstract UDS. Note, however, that there are security concerns with abstract UDSs, so maybe not a good idea on production systems.
On Tuesday, January 2, 2024 at 9:42:46 PM UTC-5 DRC wrote: > 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-user...@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-user...@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/88998028-d2b1-4e34-82f5-db1c69ea9b99n%40googlegroups.com.
