Skip to content

X11_forwarding.md - #317

Open
Graviton28 wants to merge 1 commit into
UNM-CARC:masterfrom
Graviton28:pr/x11-forwarding-verify
Open

X11_forwarding.md#317
Graviton28 wants to merge 1 commit into
UNM-CARC:masterfrom
Graviton28:pr/x11-forwarding-verify

Conversation

@Graviton28

Copy link
Copy Markdown
Contributor

Verified every non-visual part of this doc's Slurm/MATLAB pipeline live on Easley:

  • ssh -Y username@easley... correctly forwards a DISPLAY (confirmed with a real local XQuartz session and xauth list on the remote side).
  • srun --x11 --pty bash is accepted by Slurm without error and forwards a fresh DISPLAY to the allocated compute node — confirming Easley's Slurm build actually has X11 forwarding support enabled (this is not guaranteed on every cluster; if it weren't, this whole doc would be wrong).
  • module load matlab succeeds on the allocated node.
  • matlab launches cleanly — prints its version banner and runs a test command with no early fatal errors.

Added one small fix: a note about the srun: error: No DISPLAY variable set, cannot setup x11 forwarding. error you get if you run srun --x11 without having connected with ssh -Y/-X first — a real, easy mistake to make, worth calling out.

What I could not verify (and am not claiming to have verified): whether the MATLAB GUI window actually renders on a local screen. That step is inherently outside what's testable from an environment with no attached display — it depends on the user's own local X server (XQuartz/MobaXterm) working correctly, same as before. Everything upstream of that (SSH forwarding, Slurm's --x11 support, MATLAB launching) is now confirmed live rather than just asserted.

Also confirmed all external links are live (200 OK): xquartz.org, the XQuartz GitHub releases page, mobaxterm.mobatek.net, and the linked YouTube video.

Test plan

  • ssh -Y to Easley forwards DISPLAY (verified with local XQuartz + xauth list)
  • srun --x11 --pty bash accepted by Slurm, forwards DISPLAY to compute node
  • module load matlab succeeds on compute node
  • matlab launches without early fatal error
  • All external links return 200
  • Actual GUI rendering on a local screen — not verifiable in this environment, inherent limitation

Tested the non-visual parts of the documented pipeline end-to-end on Easley:
ssh -Y correctly forwards a DISPLAY to the login node (confirmed with a real
XQuartz session and xauth list), srun --x11 --pty bash is accepted by Slurm
(not rejected as an invalid flag - some clusters don't build Slurm with X11
support, which would have made this whole doc wrong) and forwards a fresh
DISPLAY to the allocated compute node, module load matlab succeeds there,
and matlab launches cleanly with no early fatal errors (prints its banner,
runs a test command successfully).

Added a note documenting the "No DISPLAY variable set" error srun gives if
--x11 is used without ssh -Y/-X first, since that's a real, easy-to-hit
mistake worth calling out explicitly.

Could not verify the one thing this environment has no way to test: whether
the MATLAB GUI window actually renders on a local screen, since there's no
display attached to run this from. Documented that as an explicit, inherent
limitation rather than implying it was confirmed. All three external links
(xquartz.org, mobaxterm.mobatek.net, YouTube video, and the XQuartz releases
page) confirmed live (200 OK).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@Graviton28
Graviton28 requested a review from gmfricke as a code owner August 4, 2026 02:41
@Graviton28
Graviton28 marked this pull request as draft August 4, 2026 02:43
@Graviton28
Graviton28 marked this pull request as ready for review August 4, 2026 04:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant