Tips

Restoring tmux Sessions

I’ve been a big fan of tmux since I started using it in 2014. I use it locally for multiplexing my terminal, and in combination with mosh it’s also fantastic for work on remote servers. My main issue with it is losing my sessions when a box restarts. Luckily there’s plugins for tmux that solve this problem!

Prerequisites

  • tmux (brew install tmux on OS X)
  • TPM (tmux plugin manager). See https://github.com/tmux-plugins/tpm#installation for installation instructions.

Setup

There are two plugins I recommend: tmux-resurrect and tmux-continuum. tmux-resurrect enables saving and restoring tmux sessions manually, while tmux-continuum saves automatically and allows for automatically restoring from the last save when tmux is started. To enable these settings, add the following to your ~/.tmux.conf:

set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'

set -g @continuum-restore 'on'

Usage

With this configuration, there’s no need to do anything manually. Your tmux sessions will be automatically saved every 15 minutes and automatically restored when tmux is started (e.g. after a reboot). You can manually save with prefix-Ctrl-s and manually restore with prefix-Ctrl-r if desired.

Note that this won’t restore running applications. tmux-resurrect has an optional configuration for doing so, but I’ve left this off for the time being.

Bugs with Non-Alphanumeric Credentials for AWS

I've recently had a chance to be working with AWS and S3 and encountered a somewhat frustrating bug that I wanted to share. I was using boto3, an AWS SDK for Python. I had created a script that would list the EC2 instances that make up an EMR cluster. It worked fine with my credentials, but another user would be a SignatureDoesNotMatch error every time. We spent a lot of time comparing the environment setup and permissions on the two accounts, but everything lined up. We started guessing a little more wildly when we noticed that my AWS credentials (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) were entirely alphanumeric, but the other user's were not. My first thought was that there was some kind of encoding error, but I had no luck with that. After some searching I found this longstanding bug with the same issue. As it turns out having non-alphanumeric credentials can cause this error and has for at least a couple of years. The only fix is to regenerate the credentials until getting a set that is entirely alphanumeric.

I later ran into the same signature error trying to distcp some data from HDFS to S3, but I knew what to look for this time. HADOOP-3733 is a very similar issue to that in boto3, but this is fixed in Hadoop 2.8.0.

This was a troublesome bug for me, so hopefully this post helps someone else who encounters the same issue.