On 18 Jan 2024 at 11:45, 'DRC' via TurboVNC User Discussion/Suppor wrote: Date sent: Thu, 18 Jan 2024 11:45:07 -0500 Subject: Re: [TurboVNC-Users] Cannot connect locally to TVNC 3.1 on Ubuntu 22.04 From: "'DRC' via TurboVNC User Discussion/Support" <turbovnc-users@googlegroups.com> To: turbovnc-users@googlegroups.com Organization: The VirtualGL Project Send reply to: turbovnc-users@googlegroups.com
> > Never mind. I am able to reproduce the issue by starting the TurboVNC session > first, then > logging in locally with a Wayland session. Once the local Wayland session is > logged in, > gnome-calculator (as an example) will always display to the Wayland session, > even if it is > started in the TurboVNC session. > Setting GDK_BACKEND=x11 fixes the issue for GNOME-specific applications, such > as the > calculator, and it also fixes the issue whereby I could not start a > GNOME/TurboVNC session > while a local Wayland session was active. However, I still cannot start a > TurboVNC session > from within the local Wayland session. I have to start the TurboVNC session > from an SSH > session. I am still investigating, so stand by. > Just wondering? With the wayland and later gnome on Fedora, I always had issues with trying to run a local vnc connection with tigervnc. I've had no problems using XFCE. Seems the wayland and gnome 3 don't like multiple logins. In /etc/sysconfig/tvncservers have this ## is port number. VNCSERVERS="##:msetzerii" VNCSERVERARGS[##]="-wm xfce" > On 1/18/24 10:52 AM, DRC wrote: > I cannot make a TurboVNC session run simultaneously with a local Wayland > session at > all. Thus, I can't reproduce the circumstances under which you observe the > issue > below. On Ubuntu 20.04, Ubuntu 22.04, and Rocky 9, if I attempt to start a > TurboVNC > session while a local Wayland session is active, the window manager in the > TurboVNC > session immediately fails, and the failure screen is displayed on the Wayland > session > rather than in the TurboVNC session. This is true regardless of whether I > attempt to start > the TurboVNC session from the local Wayland session or from an SSH session, > so it has > nothing to do with environment variables. > Thus, I need you to describe exactly how you are starting the local and > TurboVNC > sessions, and in what order. That will hopefully allow me to understand how > to > reproduce the issue. I may have misunderstood that you were using a local > Wayland > session rather than Xorg. I will reiterate that it is difficult to collate > such information > from multiple simultaneous bug reports on a mailing list. > > On 1/17/24 5:14 PM, DRC wrote: > Can you verify whether the WAYLAND_DISPLAY environment variable is set in the > TurboVNC session? That could be the cause. If you started the TurboVNC > session from > a shell in the local (Wayland) session, then the TurboVNC session may have > picked up > the WAYLAND_DISPLAY environment variable, and that may have caused certain > applications running in the TurboVNC session to display to the local > (Wayland) session > rather than to the TurboVNC (X11) session. > Try unsetting WAYLAND_DISPLAY when you run the applications in the TurboVNC > session, e.g. > WAYLAND_DISPLAY= gcalculator > If that fixes the problem, then I can modify xstartup.turbovnc and make it > unset that > environment variable automatically. > > On 1/16/24 2:22 PM, Torsten Kupke wrote: > Hi DRC, > unfortunately I have to proceed this thread. When working locally > again on the machine running theTVNC server 3.1 on Ubuntu 22.04, I > detected, that some windows of applications provided with Ubuntu (at > least the calculator and the system log) and started from within the > locally running TVNC client are still overlaid on the native desktop. > When the client is in fullscreen mode, they are completely hidden and > become only visible, when the client leaves the fullscreen mode. And > then again I can see the only icon residing on the desktop (called > "Home") twice with a small diagonal offset between both. However, > inside the TVNC client window that icon is visible a third time (which > is expected in this case). > Very annoying is the fact, that mostly (sometimes there are > exceptions) it is not possble to activate those windows by simply > clicking into them. Instead I have to click onto the icon representing > those windows in the dock bar to be able to work with them. And then, > when I want to proceed my work inside the TVNC client, I have to > click onto its icon in the dock bar of the local session. Simply clicking > into the TVNC client instead does nothing. I think, this behaviour has > to do with the overlaid desktop. So my question would be, whether it's > possible to avoid displaying it and showing those application windows > only inside the TVNC client, when started inside (as it was under > Ubuntu 18.04). > Apart from this, when I start those applications from within the TVNC > client running on my home PC, I can see their windows also in > fullscreen mode. > BR > tkansgar > Am 05.01.2024 um 00:41 schrieb 'DRC' via TurboVNC User > Discussion/Support: > 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 > theremote 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-497 > 1-bc59-1f1edf5f508en%40googlegroups.com. > -- > 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-4b4 > e-841e-f9598acee91b%40t-online.de. > > -- > 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-4e3 > 4-82f5-db1c69ea9b99n%40googlegroups.com. > -- > 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/f773c5c7-e600-4462 > -9302-184a12e2f57b%40t-online.de. > > -- > 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/ac405f57-435c-d2ac- > bfda-4025b8007f37%40virtualgl.org . +------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mi...@guam.net mailto:msetze...@gmail.com mailto:msetze...@gmx.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+ -- 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/65A98F3C.30580.C69599D%40msetzerii.gmail.com.
