This is the first post in a series which will go over some of the computing tools and practises that make my life as a scientific researcher easier. Today I will tell you about tmux and some of its use cases. Tmux is a modern terminal multiplexer and has become an extremely useful component of my remote data analysis and software development workflow.
Both in industry and in many scientific disciplines, some datasets are too big to be conveniently handled by a personal computer. For example, I could not even think about processing a several TB dataset from the CMS experiment solely using my Mid-2014 Macbook Pro notebook (i.e. 4-cores, 8 GB RAM, 128 GB SSD).
Luckily enough, research institutions and companies nowadays provide an infrastructure of remote computing resources (e.g. computing clusters, storage solutions, distributed file systems and/or virtual machine instances on demand).
While in theory the use of remote computing resources is a huge advantage over local systems in terms of management, reliability and powerfulness, people used to work locally sometimes have a rough time adapting to a remote computing paradigm. An important part of this blog series will be dedicated to solve issues which might arise in this transition.
Today we will deal with remote session persistence and session/window management, but in the near future I will also tell you how to access remote data as if it was in your computer and interactively carry out data analyses/visualize the results remotely using only your web browser.

Imagine you just got access to a remote machine provided by your institution (e.g. the lxplus linux service at CERN). You connect to it through SSH from your local computer, set up a development environment and start working right way.
However, your network connection happens to be a bit shaky and you suddenly get disconnected, so your SSH session breaks and whatever you are running is killed. In addition, every time you reconnect you have to set up again your development environment.
In a way, when you use standalone SSH access, the processes you are running are coupled to the terminal you are using to access, so if the connection breaks they are killed. By using a terminal multiplexer, like tmux (or its ancient ascendant GNU Screen), you add an intermediate layer between your processes and terminal sessions and your session, so if you detach or the connection breaks, everything keeps running in the background and you can attach to it again when you reconnect.
Tmux is becoming an increasingly popular tool, so it is probable that it is already installed in your remote computing system. For example, at the time of writing this post, the default SLC 6.8 nodes of lxplus @ CERN have tmux 1.6 installed, which is enough for basic usage but misses some useful new features.
If you have administrator privileges in the remote system you can install it from the official distribution repositories (e.g. sudo apt-get install tmux for ubuntu-based distributions), or run this script (tested in lxplus) to build a static executable for the latest tmux currently available.
So now you have tmux available in your remote system. To start it for the first time you only have to run:
tmux
A new tmux session will be started, opening a new virtual terminal and a status bar will appear at the bottom of the terminal. Now we can work as we would usually do. After a while, you need to attend a meeting or get some food, so you just close the terminal (a better practise is to detach first but more on that later). Some minutes/hours/days later you are full of new ideas (or just food) and are ready to continue what you started, so you access the same machine again and reattach to the tmux session:
tmux a
After that command, everything will be exactly as you leave it, because it had been kept running in the background. The point of accessing the same machine is really important, especially for load balanced clusters as lxplus @ CERN. Basically, when you access lxplus, by default you are assigned to a certain machine with low workload, so resources are better distributed among the users. However, you cannot access a background process in a different machine, so in this case we want to make sure that we access the same machine every time. An easy way to overcome the load balancer is to get the hostname of the computer we are going to run tmux on and then just SSH directly to this machine:
ssh -Y username@lxplus071.cern.ch # the last part is the hostname
So far we have gone through the simplest use case of tmux, which is keeping processes alive when we close the SSH access terminal. However, the real powerfulness of tmux is that it is like a “window” manager, but for your terminal sessions. After you attach to your tmux process for the first time, you only get a single terminal and the status bar. However, the actual magic is that you can split this terminal in panes or create new windows, all within the same tmux session and they will all be there when you reconnect and reattach.
Imagine that you are working on a script and you want to test it and see the result and the code simultaneously in your terminal. You can split the window in two panes with the default shortcut (Ctrl-b + %) and then comfortably work in split terminal mode. In this way, tmux also takes over part of the use cases of fancy terminal clients like iTerm2 (Mac OS X) or terminator (Linux), which I know some of the members of this network use.

That would have to suffice as a basic presentation of tmux and its use cases, for more advanced uses you can check out the O(1o00) tutorials and posts available on the internet regarding this tool (e.g. this one and this one are quite extensive).
Beware that tmux is a fully configurable and extendable tool, both aesthetically and in usability, so you can spend hours setting up your development environment to your liking instead of doing actual work. I might talk about software configuration files (a.k.a. dotfiles) and how to keep them synced between machines in a future post of this series, but the other two topics I mentioned at the beginning, e.g. how to access remote data as if it was in your computer and how to interactively carry out data analyses/visualize the results remotely using only your web browser, are first in the queue.
If you have any doubts about terminal multiplexing, want to give me some feedback about this post in particular or the perks of working on remote computers, please do so in the comment section. See you around!
23 September 2016 at 14:52
I was recently advised to start using screen. Would you recommend tmux over screen?
LikeLike
26 September 2016 at 14:21
Hi Ronan,
yes, tmux is a modern alternative to screen. It is better designed, can be configured more easily and has some additional useful functionalities. I will mention the main differences between tmux and screen taken from the tmux FAQ (https://raw.githubusercontent.com/tmux/tmux/master/FAQ):
—
* How is tmux different from GNU screen?
tmux and GNU screen have many similarities. Some of the main differences I am
aware of are (bearing in mind I haven’t used screen for a few years now):
– tmux uses a client-server model. Each server has single Unix domain socket in
/tmp and within one server there are multiple sessions which may be attached
to multiple clients (terminals).
This has advantages, notably: windows may be linked simultaneously to
multiple sessions; windows may be moved freely between sessions; and a client
may be switched between sessions easily (C-b D). There is one major
disadvantage: if the server crashes, game over, all sessions die. In
practice, however, tmux is quite stable and gets more so as people report any
bugs they hit :-).
This model is different from screen, where typically each new screen instance
is independent. tmux supports the same behaviour by using multiple servers
with the -L option but it is not typically recommended.
– Different command interfaces. One of the goals of tmux is that the shell
should be easily usable as a scripting language – almost all tmux commands
can be used from the shell and behave identically whether used from the
shell, from a key binding or from the command prompt. Personally I also find
tmux’s command interface much more consistent and clearer, but this is
subjective.
– tmux calls window names (what you see in the status line) “names”, screen
calls them “titles”.
– tmux has a multiple paste buffers. Not a major one but comes in handy quite a
lot.
– tmux supports automatically renaming windows to the running application
without gross hacks using escape sequences. Its even on by default.
– tmux has a choice of vi or emacs key layouts. Again, not major, but I use
emacs so if tmux did support only one key set it would be emacs and then all
the vi users would get humpy. Key bindings may be completely reconfigured in
any case.
– tmux has an option to limit the window size.
– tmux has search in windows (C-b f).
– The window split (pane) model is different. tmux has two objects, windows and
panes; screen has just windows. This difference has several implications:
* In screen you can have a window appear in several layouts, in tmux a pane
can only be in one window (fixing this is a big todo item but quite
invasive).
* tmux layouts are immutable and do not get changed unless you modify them.
* In tmux, all panes are closed when you kill a window.
* tmux panes do not have individual names, titles and so on.
I think tmux’s model is much easier to manage and navigate within a window,
but breaking panes off from and joining them to windows is more clumsy.
tmux also has support for preset pane layouts.
– tmux’s status line syntax is more readable and easier to use. I think it’d be
hard for anyone to argue with this. tmux doesn’t support running a command
constantly and always using the last line of its output, commands must be run
again each time.
– tmux has modern, easily extended code. Again hard to argue screen is better
if you have looked at the code.
– tmux depends on libevent. I don’t see this as a disadvantage: libevent is
small and portable, and on modern systems with current package management
systems dependencies are not an issue. libevent brings advantages in code
simplicity and performance.
– screen allows the window to be bigger than the terminal and can pan around
it. tmux limits the size to the largest attached client. This is a big todo
item for tmux but it is not trivial.
– screen has builtin serial and telnet support; this is bloat and is unlikely
to be added to tmux.
– Environment handling is different.
– tmux tends to be more demanding on the terminal so tends to show up terminal
and application bugs which screen does not.
– screen has wider platform support, for example IRIX, and for odd terminals.
—
Best regards,
Pablo
LikeLike
16 July 2017 at 20:57
Hi Pablo,
After using your script to install tmux locally on my lxplus account I’m running into this very annoying problem of not being able to reattach to my tmux session between SSH sessions. Do you see this behavior as well? I can create a session, detach from it, reattach in the _same_ ssh session, and everything works fine. However, if I try to reattach after exiting SSH and logging back in, I get the error “open terminal failed: missing or unsuitable terminal: xterm-256color”. If I use the native 1.6 version in /usr/bin/tmux then everything works (but then, as you say, there are many features missing). Any help will be appreciated.
Thanks!
LikeLike
17 July 2017 at 12:18
Hi Andre,
I assume your are entering always the same lxplus machine specifying the number when acessing by ssh. Are you using any custom tmux.conf?
Give the error message, the first thing I would try is to change the the TERM enviroment variable (i.e. export TERM=xterm and also try export TERM=screen if the previous does not work) before opening tmux and also when you log back in before attaching (you can put it in your bash/zsh init script).
Best regards,
Pablo
LikeLike
29 November 2018 at 22:16
Hi Pablo,
After a year I decided to give it another try and I finally found what was wrong with my setup. Posting here in case someone else may benefit.
The problem was that for some reason the terminfo database was missing in my sessions. I’m not sure why it happened to me but not to you since I followed your procedure pretty closely, but in any case explicitly setting the location of the terminfo database seemed to do the trick. Basically running “export TERMINFO=/usr/share/terminfo” before creating a new tmux session solved it. I can now successfully reattach to an existing tmux session after a new SSH login.
All of this is better explained in this reference: https://www.mail-archive.com/tmux-users@lists.sourceforge.net/msg01272.html.
Thanks for your help.
LikeLike