LabVIEW 2026 Container doesn't start X display when running labview-built executables

[jimkring]

Inside the nationalinstruments/labview:2025-q3patch1-linux container, executables built in LabVIEW 2020 run just fine:

root@1daae1ef45b1:/app# '/usr/local/jki/vipm/support/VIPM File Handler'
 Error opening container cache file '/tmp/natinst/LVContainer.txt': No such file or directory. The file may not exist yet, or you may lack permission to access it. We would try to create the file now.
root@1daae1ef45b1:/app# 

However, inside the nationalinstruments/labview:2026-q1-linux container, this same executable does not run, with the error that it cannot open an X display:

root@796a2c3c5e4f:~# '/usr/local/jki/vipm/support/VIPM File Handler'
 Unable to open X display.

My guess is that something has changed about how the runtime engine starts X11/xvfb.

[jimkring]

Note that I was able to work around this error message by running this script before attempting to run my executable:

#!/usr/bin/env bash
# Bootstrap a headless X display + LabVIEW container marker so the
# LabVIEW Runtime Engine (used by `vipm install` and vipm-desktop)
# can initialize inside this Docker container.
#
#   source ./bootstrap-display.sh    # inherit DISPLAY in the current shell
#   ./bootstrap-display.sh           # start Xvfb without polluting the env
#
# Safe to invoke multiple times — skips Xvfb if one is already running.
set -e

if ! pgrep -x Xvfb > /dev/null; then
    Xvfb :99 -screen 0 1280x720x24 -ac +extension GLX +render -noreset \
        > /tmp/xvfb.log 2>&1 &
fi

mkdir -p /tmp/natinst
echo "1" > /tmp/natinst/LVContainer.txt

export DISPLAY=:99

echo "X11 ready: DISPLAY=$DISPLAY (Xvfb log: /tmp/xvfb.log)"

[gregr-ni]

The 25Q3 container started an X server. 26Q1 and beyond will not because we introduced the --headless command line option that avoids the need to have an X server.

If you are trying to use older runtimes with the latest containers, then you will need to manually start an X server as you did in your workaround.

[jimkring]

Thank for the info, Greg.

BTW, within the 26Q1 container, running labview without the --headless option does start the X server.

I don't think the vipm binary is using an older (than 26Q1) run-time engine (RTE), since it was built with the option to work with newer runtime engines, but it might be using an earlier RTE if earlier ones are installed onto the container. VIPM for Linux does not install a LVRTE itself.

User Need: As a user of the shipping LabVIEW container, my need/expectation is that the container will "just work, out of the box, for running my headless, built (with labview) applications". The requirement to start up an X server myself feels like a regression and undue burden--the container should make this easy-if-not-transparent for me (the user).

A different question/angle: Can I run vipm (or other apps built in LabVIEW 2026+) headless? Meaning: can I pass --headless into vipm, if it's built using LV2026? or, if it's running under the LV2026 RTE? If we're going to ship VIPM on the LabVIEW container, or provide a separate container, built FROM the official LabVIEW container, then we're going to need to address the requirement of either a --headless mode or starting an X server. So, I'm wondering the best path forward.

[shivaCode-2]

@jimkring - I agree with Greg. We have changed on how LabVIEW starts the X Server and unless the --headless argument is passed, the server won't start from LabVIEW or RTE
That said, we still have another global override to always start an X Server.
If you set LV_RTE_HEADLESS=1 in your environment variables, LabVIEW and RTE do not need the --headless argument. They will automatically run in headless mode.

I have updated the documentation to add this information as well. Ref: Setting Headless Mode as default

Please let us know if setting this environment variable works for you.

cc @gregr-ni

[shivaCode-2]

@jimkring -
A different question/angle: Can I run vipm (or other apps built in LabVIEW 2026+) headless? Meaning: can I pass --headless into vipm, if it's built using LV2026? or, if it's running under the LV2026 RTE?

• Yes, applications built using LabVIEW 2026 Q1 and later do support the --headless argument.

[jimkring]

@shivaCode-2

Yes, applications built using LabVIEW 2026 Q1 and later do support the --headless argument.

What about applications built in earlier versions of LabVIEW, but running via the run-time engine of LabVIEW 2026 Q1 or later (using the "compatible with newer versions of the LV runtime engine")?