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!


  • tmux (brew install tmux on OS X)
  • TPM (tmux plugin manager). See for installation instructions.


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:


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.