Tmux interactive session app


I’m looking for a way to create an “Interactive App” that starts a long lasting tmux session that the user will be able to connect and disconnect from. Similar to a VNC session, but console based. I was thinking if there was a way to specify a tmux session like you can specify a directory in the /pun/sys/shell/ssh app, this would make it much easier. Has anyone done anything like this?


You could get something really quickly by taking something like the Matlab application and replacing the matlab command with the command to start a terminal…? It would run in a very minimal VNC, but it’s in a browser window, so they don’t need a VNC client installed.

That would also give them access to scrollback buffer and other terminal functions that require special command sequences when in Tmux, and you won’t have people accidentally typing Ctrl-B something and getting to some Tmux function they didn’t intend.

Finally, they would also be able to start a second terminal window, and having two terminals can sometimes be really helpful, e.g., when running a program in one and top in another.

I know this is answering a different question, but I think it addresses the same scenario and overall desire. Sorry if I have gone too far astray.

Thanks @bennet, I think you’re spot on.

There’s a similar discussion here. Regardless of how you schedule (through Slurm or the linux host adapter) - a VNC batch connect app will persist for as long as you like.

The last 2 comments in that topic specifically have some example apps.

Thanks, @jeff.ohrstrom

To clarify a bit here, the reason I chose the Matlab application to start rather than VNC is that the Xfce desktop is empty, no dock, so the terminal window will not be lost in ‘clutter’

By replacing the matlab command with one of the terminal commands to run in full screen, e.g.,

# Pick your favorite terminal
# /bin/gnome-terminal --full-screen
# /bin/xfce4-terminal --maximize

you’d get basically a ‘terminal application’.

The window manager Application menu is there, but it is very stripped down and contains only Firefox, Terminal emulator, and the File manager, all of which could be handy to have ‘right there’.

I can’t do much these days without looking something or other up on the web, and having a handy copy-and-paste is very useful. Having the reference material from the web next to the Terminal has distinct advantages.

I think many students might find the File manager also useful.

I am pretty sure this is how I would do this here, if we had a call for it.

Thanks everyone, I have a working VNC xfce4-terminal app now. I might still work on a hterm or vncterm version for the better performance.



I was able to do what you are trying to do using a program called ttyd and tmux. Only downside I could find is that the only way to stop the interactive job is to delete the card in OOD (really wish there was a stop/cancel button that left the card in place). I can’t share our code directly since our GitLab is not publicly available but if you are really interested I will see if I can rehost it.

Also, for using ttyd, and many other applications that end up having sensitive info like passwords in the command, it is important to do some system hardening around /proc. Specifically the hidepid mount option to prevent users from seeing processes that don’t belong to them.

I also forgot to mention that you need to be very careful with tmux. When spawning tmux inside Slurm jobs you need to make sure tmux uses a unique socket name/path. If you don’t tmux escapes it’s cgroup if the users launches it inside a second job on the same node.

I’d also be interested in seeing how you do ttyd and tmux together :slight_smile:

See if this link works NMSU_HPC / ood_bc_shell · GitLab

It’s important to note I had to build ttyd from it’s master branch as there is an unreleased fix for reverse proxies (-b flag). This is as of version 1.6.3. Also if you use Spack to build ttyd the default recipe in develop for libwebsockets needs to be asjusted

Thanks for sharing this, looks very promising. I’m going to give it a try next week.

I went ahead and added a mirror for our spack recipes if you need a reference for building ttyd.

  • ttyd
  • libwebsockets
  • openssl (I had to backport it to 0.16 from develop. develop introduced a new flag called ‘docs’ which broke a lot of things as the flag does more then just enable/disable documentation. Just a heads up.)

@nvonwolf I just wanted to say thanks for sharing, this is really nice. I gave it quick spin, but I see persistence on an interactive session, yes! It works in our test cluster at Georgia Tech. Obviously, some form customizations aside, to over come some roadblocks I needed to get it going

set TERM to something that’s on our RHEL7 systems, e.g.

export TERM=xterm-color

There were some funky complaints (but warnings) with the default tmux.conf that I have yet to diagnose further

tmux.conf:79: usage: bind-key [-cnr] [-t key-table] key command [arguments]  
tmux.conf:80: usage: bind-key [-cnr] [-t key-table] key command [arguments]
tmux.conf:81: usage: bind-key [-cnr] [-t key-table] key command [arguments]
tmux.conf:27: ambiguous option: mouse
tmux.conf:52: unknown key: \\
tmux.conf:112: unknown option: pane-active-border-style
tmux.conf:113: unknown option: pane-border-style
tmux.conf:116: unknown option: message-style
tmux.conf:119: unknown option: status-style
tmux.conf:124: unknown option: window-status-style
tmux.conf:126: unknown option: window-status-current-style
tmux.conf:128: unknown option: window-status-activity-style
tmux.conf:129: unknown option: window-status-bell-style

Other points mostly related to build of ttyd

While we have Spack at our site, on RHEL7.6, I skipped using for building ttyd, and went with a manual build. All prerequisite problems were resolved with the installation of libwebsockets-devel and dependencies. I used your advice to build ttyd against the latest git.

I’ll be glad to give more feedback next week.

tmux on C7 is much older. You can likely solve the issues by writing your own tmux.conf or updating tmux (which at most sites is not an option).

Sorry, meant to write EL7.

As far as the “TERM” env, and set -g default-terminal "screen-256color" in tmux.conf, I’m unfamiliar with the correct/desirable values. I managed to land on something that worked and didn’t question it.

For tmux we provide a newer version of tmux on our cluster via Spack and lmod. The config file I bundled is based on tmux 3.2b. I’m not aware of a simple way make tmux configs backwards compatible which is probably my largest complaint about tmux to be honest.

Also, I pushed an update that removed our site specific config from the ‘view.html.erb’ file in favor of a more dynamic method.


I just caved and built the newer tmux, less fighting with the default tmux.conf configuration (which was already pretty nice to begin with). Haven’t tried the ‘more dynamic’ method but I can give that a go soon.

Thanks again.


The ‘more dynamic’ is just using some javascript to get the base url since i’m not sure I can add a username/password to a relative path. I put in a fix for the “TERM” variable as some users were getting an error that it was set to “unknown” for some reason. Eventually I intend to put in a drop down so users can select what version of tmux they want (incase they want to use the tmux.conf in their home directory and it needs a specific version).

@nvonwolf Separately, I have done some testing along with a fellow staffer. Have you seen issues with different web browsers for the click button passthrough to connect? On Safari and Firefox, the username and password are prompted (for which one needs to supply username = ttyd and password from connection.yml).

No issues with Chrome (connect just ‘works’). Maybe there’s a more general issue at play not specific to this app.

EDIT: maybe your sentence related to ‘username/password to a relative path’ was related.
Anyhow I can just retry testing with the latest version and follow up here.

Also @nvonwolf , since we don’t do the hidepid technique at our site (yet :slight_smile: ), I modified the app so that it would read off the connection.yml and writing a simple auth script using ttyd's --url-arg option. That way the use of plaintext passwords being shown on the CLI can be avoided.

@kevinlee I was unable to get the --url-arg feature working myself and having the password shown in the url was not desirable (would show in screen sharing and such). If you do get it working I would be interested to see what it looks like though.