Problems with Stata as Interactive application

Working with OOD 3.0.3, I have been trying to add Stata as an interactive application.
Using a copy of a MATLAB application, which works well, I am seeing that Stata will launch, but then close, but I don’t see any errors reported. I did see a previous post about Stata from 2021: Unable to get Stata working on OOD
However, this was caused by Stata going into the background, so is not the same as my issue.
As I am able to launch Stata from a Xfce4 desktop launch from OOD, I tried customising a version of this, and add Stata as a startup application. To do this, I created an extra entry in the xfce4 startup area, and edited the xfce.sh script which launches the desktop, to ensure the entry is copied appropriately:

# Copy startup for Stata 8 core
cp /gpfs01/software/stata18/Stata-8.desktop “${AUTOSTART}”

This works, but is a bit of a hack. Has anyone seen behaviour similar to this, or have any idea what might be happening, or how to investigate further ?

Thanks for any help,
Colin

You have good timing. I’ve just been updating stata at OSC.

Are you sure back-grounding isn’t still your issue? While in an actual desktop this is fine for you to background stuff, but if it’s it’s own application - something (in script.sh.erb) has to stay in the foreground. By your description - it launches, then closes with no errors - sounds like it was backgrounded. Which again, can’t happen. script.sh.erb has to be actively running the entire duration of a job.

You can checkout our repository for how we keep the script in in the foreground.

Hi Jeff, thank you very much for the swift response.

I don’t think my issue is caused by back-grounding. I do have the additional commands in my script.sh.erb to check the stata PID, and use ‘sleep’ to keep the job going. You can see in the output.log that this works for a bit, but the stata process disappears fairly quickly - full output.log below:
Setting VNC password…
Starting VNC server…

Desktop ‘TurboVNC: comp033.int.ada.nottingham.ac.uk:1 (cczcb)’ started on display comp033.int.ada.nottingham.ac.uk:1

Log file is vnc.log
Successfully started VNC server on comp033.int.ada.nottingham.ac.uk:5901
Script starting…
Starting websocket server…
The system default contains no modules
(env var: LMOD_SYSTEM_DEFAULT_MODULES is empty)
No changes in loaded modules

(xfwm4:3563098): GLib-CRITICAL **: 09:44:56.529: g_str_has_prefix: assertion ‘prefix != NULL’ failed
WebSocket server settings:

  • Listen on :20815
  • No SSL/TLS support (no cert file)
  • Backgrounding (daemon)
    Scanning VNC log file for user authentications…
    Generating connection YAML file…

Currently Loaded Modules:

  1. stata-uoneasy/8/18

DISPLAY is :1
Current directory is /gpfs01/home/cczcb
++ xstata-mp
+++ pgrep -u cczcb xstata-mp
+++ tail
++ stata_pid=3563143
++ [[ -d /proc/3563143 ]]
++ sleep 1
++ [[ -d /proc/3563143 ]]
++ sleep 1
++ [[ -d /proc/3563143 ]]
++ sleep 1
++ [[ -d /proc/3563143 ]]
++ sleep 1
++ [[ -d /proc/3563143 ]]
Cleaning up…
Killing Xvnc process ID 3563068
xsetroot: unable to open display ‘:1’
Unable to init server: Could not connect: Connection refused

(xfsettingsd:3563242): xfsettingsd-ERROR **: 09:45:03.810: Unable to open display.
/gpfs01/home/cczcb/ondemand/data/sys/dashboard/batch_connect/sys/test-application-3/output/f9c1d170-cd86-41f2-9b5a-fed04018839c/script.sh: line 18: 3563242 Trace/breakpoint trap (core dumped) xfsettingsd --sm-client-disable
Unable to init server: Could not connect: Connection refused
xfce4-panel: Cannot open display: .
Type “xfce4-panel --help” for usage.

For my version of Stata (18), there is an option for command xstata-mp which is supposed to set it to notfork to background. If I try this, the Stata process ends even sooner, so no PID is recorded. This time, there is a ‘terminated’ message:

Currently Loaded Modules:

  1. stata-uoneasy/8/18

DISPLAY is :1
Current directory is /gpfs01/home/cczcb
++ xstata-mp -f0
/gpfs01/home/cczcb/ondemand/data/sys/dashboard/batch_connect/sys/test-application-3/output/0fd08c9a-d0c2-4a78-94e9-803e7fb85fe2/script.sh: line 36: 3568166 Terminated xstata-mp -f0
+++ pgrep -u cczcb xstata-mp
+++ tail
++ stata_pid=
++ [[ -d /proc/ ]]
++ sleep 1
++ [[ -d /proc/ ]]
++ sleep 1
++ [[ -d /proc/ ]]
++ sleep 1
++ [[ -d /proc/ ]]
++ sleep 1
++ [[ -d /proc/ ]]
++ sleep 1
++ [[ -d /proc/ ]]
++ sleep 1
++ [[ -d /proc/ ]]
++ sleep 1
++ [[ -d /proc/ ]]
++ sleep 1
Setting VNC password…
Generating connection YAML file…
++ [[ -d /proc/ ]]
++ sleep 1
++ [[ -d /proc/ ]]
++ sleep 1
++ [[ -d /proc/ ]]

It does seem the VNC desktop loads something that is needed for Stata to run on our system compute nodes, which the interactive application lacks. The script.sh.erb is a bit different from the one from the repository, but seems to do pretty much the same. It does work fine for other applications, e.g. MATLAB. Below is the version used for latest test:
#
# Launch Xfce Window Manager and Panel
#

(
export SEND_256_COLORS_TO_REMOTE=1
# It will override without replacing any XFCE settings that the user
# already has.
export XDG_CONFIG_HOME=“<%= session.staged_root.join(“config”) %>”
export XDG_DATA_HOME=“<%= session.staged_root.join(“share”) %>”
export XDG_CACHE_HOME=“$(mktemp -d)”
module restore
eval $(dbus-launch --sh-syntax)
xfwm4 --compositor=off --sm-client-disable
xsetroot -solid “#D3D3D3
xfsettingsd --sm-client-disable
xfce4-panel --sm-client-disable
) &

cd “$HOME”

#
# Start application
#

# Load the required environment
module load <%= context.stata_version %>
#module load mesa-uoneasy/23.1.9-GCCcore-13.2.0
# make sure that XFCE boots up before you do
sleep 3
# Launch application
module list # List loaded modules for debugging purposes
echo “DISPLAY is $DISPLAY”
echo “Current directory is $PWD”
set -x
xstata-mp -f0
# Get the PID of the last xstata-mp process started that $USER owns
stata_pid=$( pgrep -u “$USER” ‘xstata-mp’ | tail )
# As long as the PID directory exists we wait
while [[ -d “/proc/$stata_pid” ]]; do
sleep 1
done
#sleep 120

Most grateful for any further thoughts.
Colin

Well you’re generating a core dump here after you weren’t able to start up Xvnc, so I’d guess that’s the issue.

What’s in the vnc.log? I know you’ve said you can replicate in a desktop. I guess I’d ask if you’re replicating on the same machine. I would try to get these jobs (both stata and desktops) to land on the same machine to reduce any questions about what could be installed/missing on the OS.

Hi Jeff,

The vnc.log doesn’t look to have much pointing to problems:

TurboVNC Server (Xvnc) 64-bit v3.0.91 (build 20230818)
Copyright (C) 1999-2023 The VirtualGL Project and many others (see README.md)
Visit http://www.TurboVNC.org for more information on TurboVNC

01/11/2024 09:44:54 Using security configuration file /etc/turbovncserver-security.conf
01/11/2024 09:44:54 Enabled security type ‘tlsvnc’
01/11/2024 09:44:54 Enabled security type ‘tlsotp’
01/11/2024 09:44:54 Enabled security type ‘tlsplain’
01/11/2024 09:44:54 Enabled security type ‘x509vnc’
01/11/2024 09:44:54 Enabled security type ‘x509otp’
01/11/2024 09:44:54 Enabled security type ‘x509plain’
01/11/2024 09:44:54 Enabled security type ‘vnc’
01/11/2024 09:44:54 Enabled security type ‘otp’
01/11/2024 09:44:54 Enabled security type ‘unixlogin’
01/11/2024 09:44:54 Enabled security type ‘plain’
01/11/2024 09:44:54 Desktop name ‘TurboVNC: comp033.int.ada.nottingham.ac.uk:1 (cczcb)’ (comp033.int.ada.nottingham.ac.uk:1)
01/11/2024 09:44:54 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t
01/11/2024 09:44:54 Listening for VNC connections on TCP port 5901
01/11/2024 09:44:54 Interface 0.0.0.0
01/11/2024 09:44:54 Framebuffer: BGRX 8/8/8/8
01/11/2024 09:44:54 New desktop size: 1600 x 900
01/11/2024 09:44:54 New screen layout:
01/11/2024 09:44:54 0x00000040 (output 0x00000040): 1600x900+0+0
01/11/2024 09:44:54 Maximum clipboard transfer size: 1048576 bytes
01/11/2024 09:44:54 VNC extension running!

I guess I thought that the core dump looked like it came after the closedown of Xvnc, so wasn’t the root cause of the problems, but perhaps a consequence.
I can confirm I can run the Stata application, and VNC desktop on same node. Stata will work fine from the VNC desktop, but fails as reported via the Stata application.

best regards,
Colin

I’m thinking the same thing. xsetroot: unable to open display ‘:1’ appears to be the first error you encounter.

OK if MATLAB works over VNC then this could be our best clue. Could there be some module that stata needs that’s conflicting here? I’d suggest removing STATA from the equation - see if you can get any other app, firefox, glxgears, anything really that doesn’t require a module to boot up.

Interesting - replaced xstata-mp with glxgears. Confirm this runs fine, but when I close the glxgears window, do get core dump reported in output.log:
Setting VNC password…
Starting VNC server…

Desktop ‘TurboVNC: comp033.int.ada.nottingham.ac.uk:1 (cczcb)’ started on display comp033.int.ada.nottingham.ac.uk:1

Log file is vnc.log
Successfully started VNC server on comp033.int.ada.nottingham.ac.uk:5901
Script starting…
Starting websocket server…
The system default contains no modules
(env var: LMOD_SYSTEM_DEFAULT_MODULES is empty)
No changes in loaded modules

WebSocket server settings:

  • Listen on :56592
  • No SSL/TLS support (no cert file)
  • Backgrounding (daemon)
    Scanning VNC log file for user authentications…
    Generating connection YAML file…

(xfwm4:3582503): GLib-CRITICAL **: 15:12:05.895: g_str_has_prefix: assertion ‘prefix != NULL’ failed
No modules loaded
DISPLAY is :1
Current directory is /gpfs01/home/cczcb
++ glxgears
3849 frames in 5.0 seconds = 769.550 FPS
Setting VNC password…
Generating connection YAML file…
3666 frames in 5.0 seconds = 733.064 FPS
3017 frames in 5.0 seconds = 603.208 FPS
3068 frames in 5.0 seconds = 613.496 FPS
4086 frames in 5.0 seconds = 817.176 FPS
3866 frames in 5.0 seconds = 773.066 FPS
4851 frames in 5.0 seconds = 969.975 FPS
5170 frames in 5.0 seconds = 1034.000 FPS
4895 frames in 5.0 seconds = 978.893 FPS
4749 frames in 5.0 seconds = 949.702 FPS
4976 frames in 5.0 seconds = 995.043 FPS
5071 frames in 5.0 seconds = 1014.175 FPS
4988 frames in 5.0 seconds = 997.485 FPS
5141 frames in 5.0 seconds = 1028.062 FPS
X connection to :1 broken (explicit kill or server shutdown).
Cleaning up…
Killing Xvnc process ID 3582471
xsetroot: unable to open display ‘:1’
Unable to init server: Could not connect: Connection refused

(xfsettingsd:3582740): xfsettingsd-ERROR **: 15:13:22.492: Unable to open display.
/gpfs01/home/cczcb/ondemand/data/sys/dashboard/batch_connect/sys/test-application-3/output/8df68d58-a654-443f-8e16-667b8e0f116d/script.sh: line 18: 3582740 Trace/breakpoint trap (core dumped) xfsettingsd --sm-client-disable
Unable to init server: Could not connect: Connection refused
xfce4-panel: Cannot open display: .
Type “xfce4-panel --help” for usage.

There’s something funny going on here with the timings. You see you get many frames, then the errors come. Suggesting they’re being ran out of order?

What’s your OS? It seems like we had to fix up those scripts to support el 9. Here’s what we do because some things block and somethings don’t.

I feel like there’s something silly/obvious that we’re just missing here…

That makes sense, if order of things is going wrong somehow. We are running RHEL 8.
I will try some tweaks.
Really helpful, thanks.
Colin

To be clear it’s the order of things executing, not necessarily as they’re defined. I.e., something stays in the foreground unexpectedly when it should background or complete.

You may also notice that we sleep here for a few seconds before starting STATA up. I find that this can help some situations.

Great stuff, looks like it is working now. script.sh.erb as below. Previous version seemed to group commands for xfce together, and background them all. I’ve tried out other options, and this seems to be OK. Note that with this version of Stata, the ‘-f0’ option prevents xstata-mp going into background:

# Launch Xfce Window Manager and Panel

export SEND_256_COLORS_TO_REMOTE=1
# It will override without replacing any XFCE settings that the user
# already has.
export XDG_CONFIG_HOME=“<%= session.staged_root.join(“config”) %>”
export XDG_DATA_HOME=“<%= session.staged_root.join(“share”) %>”
export XDG_CACHE_HOME=“$(mktemp -d)”
module restore
eval $(dbus-launch --sh-syntax)
xfwm4 --compositor=off --sm-client-disable &
xsetroot -solid “#D3D3D3
xfsettingsd --sm-client-disable &
xfce4-panel --sm-client-disable &

cd “$HOME”

# Start application

# Load the required environment
module load <%= context.stata_version %>
# make sure that XFCE boots up before you do
sleep 3
# Launch application
module list # List loaded modules for debugging purposes
echo “DISPLAY is $DISPLAY”
echo “Current directory is $PWD”
set -x
xstata-mp -f0

Very much appreciate the support Jeff!

thank you so much,

Colin