g-cli in Linux hangs if called from an SSH session

[MarcoPignati]

I can successfully run the g-cli "Echo" -- "Hello World" from a terminal inside a UI. However the same command seems to hang when launched from an SSH session. I suspect it has something to do with the Unable to Open X display (this issue is what made me move away from LabVIEWCLI to g-cli).

I say "hang" because, when I launch the command in the SSH session, I can manually run the Echo.vi in the UI, and in that case the message appears correctly in the std out of the SSH terminal.

[MarcoPignati]

An additional feedback, I tried running g-cli -v --lv-ver 2020 lvBuild -- "project.lvproj" "my-build" on a simple test project.

13:39:17.348 [DEBUG] G CLI Started - Verbose Mode
13:39:17.348 [DEBUG] Version 3.0.1
13:39:17.349 [DEBUG] G CLI Arguments: "g-cli" "-v" "--lv-ver" "2020" "lvBuild" "--" "project.lvproj" "my-build"
13:39:17.349 [DEBUG] Arguments passed to LabVIEW: "project.lvproj my-build"
13:39:17.349 [DEBUG] No extension in path. Assume it is a .vi
13:39:17.349 [DEBUG] Detected LabVIEW versions:
2020, 64bit (/usr/local/natinst/LabVIEW-2020-64)

13:39:17.349 [DEBUG] Looks like VI "lvBuild.vi" doesn't exist - Checking in vi.lib/G CLI Tools instead.
13:39:17.350 [DEBUG] Launching: /usr/local/natinst/LabVIEW-2020-64/labview "/usr/local/natinst/LabVIEW-2020-64/vi.lib/G CLI Tools/lvBuild.vi -unattended -- -p:37023"
13:39:17.350 [DEBUG] Process launched with PID 41648
13:39:17.401 [INFO] Process lost + found at PID 41558
Error: No connection established with application.

Caused by:
    Timed out waiting for app to connect to g-cli (Timeout: 60s)

Location:
    src/main.rs:62:10

After launching the command, I could see that the PID 41648 was .

Same command works ok when run from terminal inside of a UI.

[JamesMc86]

Sorry for the very slow reply on this - seems I missed it first time around.

I suspect you are right - LabVIEW is going to get launched from within the same shell so the lack of an XWindow session is probably going to cause a failure. I'll try and test this case and see if there is either:

1. Something we can do to avoid this - I suspect not as you would need to launch the process under a user with a window session.
2. At least provide a more useful error message!