It turned out that the reason Xvnc got killed during startup was that the regular X server wasn't running. If I start that (and keep it running) before starting the VNC server then all is well and the vgl faker libraries end up in LD_PRELOAD and interception works as expected.
There is a weird thing with that though. Since the faker libs are not present with absolute paths it seems that attempts to load them can give warnings. For example: snellius paulm@gcn50 10:21 ~/projects/opengl-triangle-bench-git/build$ git pull ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libvglfaker.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libvglfaker.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. Already up to date. This appears to come from ssh-keysign (which is used by git pull): snellius paulm@gcn50 10:13 ~/projects/opengl-triangle-bench-git/build$ /usr/libexec/openssh/ssh-keysign ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libvglfaker.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. I haven't noticed any other commands leading to this warning, but it is somewhat annoying (especially to users that don't know what it means). Plus, I do believe that the paths to the VGL fakers in LD_PRELOAD should be absolute? On Wednesday, September 25, 2024 at 9:54:06 PM UTC+2 DRC wrote: > Note that specifying TVNC_MT and TVNC_NTHREADS isn't necessary. Since > TurboVNC 2.2, the server automatically enables Tight multithreading with a > thread count equal to the number of CPU cores. > > I get the same warning about an X server already running on display :1, > but it appears to be innocuous: > > > https://forums.freebsd.org/threads/xfce-says-x-server-already-running.30863/ > > Apparently startxfce4 can start an X server if one isn't already running, > but if it is run against an existing X server, it prints the warning to > indicate that it won't start its own X server. > > I suspect that the real problem is that VirtualGL isn't working for some > reason. Start the TurboVNC Server with: > XDG_DATA_DIRS=$XDG_DATA_DIRS:/usr/local/share/:/usr/share/ \ > /opt/TurboVNC/bin/vncserver -noxstartup -geometry 1240x900 -dpi 90 > > Then set DISPLAY to the X display of the TurboVNC session you just > started, and run > > vglrun /opt/VirtualGL/bin/glxspheres64 > > I suspect that VirtualGL will fail. > > DRC > On 9/25/24 11:32 AM, Paul Melis wrote: > > So I'm trying to get this running locally on our system, but run into an > issue. > > The batch script to launch the VNC server on a compute node pretty much > does this: > > /usr/bin/X & > > TVNC_MT=1 TVNC_NTHREADS=4 > XDG_DATA_DIRS=$XDG_DATA_DIRS:/usr/local/share/:/usr/share/ \ > /opt/TurboVNC/bin/vncserver \ > -vgl -wm xfce \ > -fg \ > -geometry 1240x900 \ > -dpi 90 > > When the VNC server starts up it exits quickly: > > snellius paulm@gcn154 17:28 ~$ TVNC_MT=1 TVNC_NTHREADS=4 > XDG_DATA_DIRS=$XDG_DATA_DIRS:/usr/local/share/:/usr/share/ > /opt/TurboVNC/bin/vncserver -vgl -wm xfce -fg -geometry > 1240x900 -dpi 90 > > Desktop 'TurboVNC: gcn154.local.snellius.surf.nl:1 (paulm)' started on > display gcn154.local.snellius.surf.nl:1 > > Starting applications specified in /opt/TurboVNC/bin/xstartup.turbovnc > (Enabling VirtualGL) > Log file is /home/paulm/.vnc/gcn154.local.snellius.surf.nl:1.log > > Killing Xvnc process ID 1426621 > > Looking in the VNC log file: > > 25/09/2024 17:14:01 framebuffer updates 0, rectangles 0, bytes 0 > xstartup.turbovnc: Creating new session bus instance: > xstartup.turbovnc: > unix:abstract=/tmp/dbus-qn7ynuWttb,guid=fd2fba716838b6b1474ecf7f66f428b9 > xstartup.turbovnc: Using 'xfce' window manager in > xstartup.turbovnc: /usr/share/xsessions/xfce.desktop > xstartup.turbovnc: Executing /usr/bin/ssh-agent vglrun +wm > /etc/X11/xinit/Xsession "startxfce4" > Environment variable $XAUTHORITY not set, ignoring. > Failed to import environment: Process org.freedesktop.systemd1 exited with > status 1 > /bin/startxfce4: X server already running on display :1 > > The "already running on display :1" message is really curious. There isn't > any existing XFCE session running on the node. I found a (very old, 2014) > forum post and link to bug report that lists the same error, > https://bbs.archlinux.org/viewtopic.php?id=180965. But I'm not sure if > this is still relevant? > > This is with TurboVNC 3.1.1 and VirtualGL 3.1.1 on a RHEL9 compute node, > btw. The installed XFCE is 4.18.3. I still need to test on our regular > visualization nodes with A100s, the above is one with an H100, but I think > the startup doesn't even come close anything GPU related. > > > > On Friday, September 6, 2024 at 5:45:18 PM UTC+2 DRC wrote: > >> No downsides. As a matter of fact, TurboVNC makes that easier for you. >> You can simply pass '-vgl -wm xfce' to /opt/TurboVNC/bin/vncserver, or set >> >> $useVGL = 1; >> $wm = "xfce"; >> >> in turbovncserver.conf (under /etc for system-wide or ~/.vnc for >> per-user). The -wm argument/$wm variable correspond to a session desktop >> file under /usr/share/xsessions. In the case of Xfce, the session desktop >> file does nothing but run startxfce4, but other window managers (e.g. >> GNOME) sometimes have additional arguments or environment variables >> embedded in their session desktop files, so using -wm/$wm is the preferred >> way to start a window manager these days. >> /opt/TurboVNC/bin/xstartup.turbovnc should take care of all of the >> mechanics automatically. Also, you should use xstartup.turbovnc rather >> than overriding the X startup script, because xstartup.turbovnc sets up a >> separate D-Bus session bus instance for each TurboVNC session. (Some >> window managers, such as GNOME and MATE, need that in order to run multiple >> simultaneous sessions.) >> All window managers listed here: >> >> https://turbovnc.org/Documentation/Compatibility30 >> >> have been tested both with and without VirtualGL. >> >> DRC >> On 9/6/24 7:21 AM, Paul Melis wrote: >> >> Hi, I saw this handy tip somewhere, to start the desktop environment >> within a VNC server under vglrun, e.g. `-xstartup "vglrun xfce4"` when >> using TurboVNC with XFCE. This avoids the user within the VNC session to >> have to use vglrun for OpenGL apps, but I'm wondering if there's downsides >> to this approach that I might be missing. >> >> Paul >> >> -- >> You received this message because you are subscribed to the Google Groups >> "VirtualGL 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/virtualgl-users/cdb4028a-fbfe-4e61-b890-d663a8beefebn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/virtualgl-users/cdb4028a-fbfe-4e61-b890-d663a8beefebn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- > You received this message because you are subscribed to the Google Groups > "VirtualGL 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/virtualgl-users/45d80097-cbaf-4912-9c8a-29208ff1fecbn%40googlegroups.com > > <https://groups.google.com/d/msgid/virtualgl-users/45d80097-cbaf-4912-9c8a-29208ff1fecbn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "VirtualGL 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/virtualgl-users/3b10eac1-dfff-46d6-8482-fa817e183c1bn%40googlegroups.com.
