Ramblings of an aging IT geek
← Ramblings of an aging IT geek
tooling

the ssh dropped and i didn't lose a thing

A short note on why a tmux session on the remote box, not the local terminal, is the thing that survives a flaky connection.

A mechanical keyboard lit by a terminal

The train went into a tunnel, the SSH session died, and I didn't lose a single thing. That used to be a small tragedy: a half-finished migration, a tailing log, three windows of context, all gone because the connection blinked. Now it's a non-event, because the work doesn't live in my terminal. It lives in a tmux session on the box at the other end.

The trick is just where you start tmux. Not on your laptop. On the remote machine, first thing after you connect:

tmux new -A -s work

The -A is the bit that matters. It attaches to a session called work if one exists, and creates it if it doesn't. So I never have to remember whether I've got a session running. One command, every time, and I'm either back where I was or starting fresh. When the connection drops, the session keeps running serverside with everything exactly as it was. I reconnect, run the same command, and I'm back in the room.

That's the whole point really. tmux gets sold on splits and status bars and elaborate configs, and those are fine, but the load-bearing feature is that the session outlives the connection. Everything else is decoration. If you do nothing else, get into the habit of starting tmux on the far side and your flaky-connection problems mostly stop being problems. The tunnel can have my packets. It can't have my work.