Any downsides to "vglrun startfxce4"?

81 views
Skip to first unread message

Paul Melis

unread,
Sep 6, 2024, 11:37:44 AM9/6/24
to VirtualGL User Discussion/Support
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

DRC

unread,
Sep 6, 2024, 11:45:18 AM9/6/24
to virtual...@googlegroups.com

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 virtualgl-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/cdb4028a-fbfe-4e61-b890-d663a8beefebn%40googlegroups.com.

Paul Melis

unread,
Sep 25, 2024, 11:32:55 AM9/25/24
to VirtualGL User Discussion/Support
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.

DRC

unread,
Sep 25, 2024, 12:18:12 PM9/25/24
to virtual...@googlegroups.com

I will try to reproduce.

DRC

unread,
Sep 25, 2024, 3:54:06 PM9/25/24
to virtual...@googlegroups.com

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:

Paul Melis

unread,
Sep 30, 2024, 8:03:21 AM9/30/24
to VirtualGL User Discussion/Support
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?

DRC

unread,
Oct 9, 2024, 1:31:48 PM10/9/24
to virtual...@googlegroups.com

DRC

unread,
Oct 9, 2024, 1:53:17 PM10/9/24
to virtual...@googlegroups.com

Also, yes, the "regular" X server needs to be running in order to use VirtualGL with its GLX back end.  Refer to the VirtualGL User's Guide for more details on that.  You can also try the EGL back end, which doesn't require a "3D X server", but the EGL back end doesn't support some esoteric and legacy GLX features.

DRC

On 9/30/24 8:03 AM, Paul Melis wrote:
Reply all
Reply to author
Forward
0 new messages