79

I'm trying to upgrade to a newer version (that has a bug fix) than my current 1.6. I am on Ubuntu and recently upgraded to Ubuntu 13.04.

Ideally I want to use tmux version 1.8 or even 1.9. I've downloaded newer versions but can't get them working.

I downloaded 1.9a but when I try and run it, it just hangs.

I tried this download: http://sourceforge.net/p/tmux/tmux-code/ci/master/tree/README#l26

and did the

$ sh autogen.sh
$ ./configure && make

but I get

$ ./tmux
$ protocol version mismatch (client 8, server 6)

I tried to download and use a 1.8.4 version but the download didn't seem to have files I could use.

tshepang
  • 64,472
  • 86
  • 223
  • 290
Michael Durrant
  • 41,213
  • 69
  • 165
  • 232

6 Answers6

249

Pretty awesome hack, if you need your tmux working and not want to lose all your sessions:

$ tmux attach
protocol version mismatch (client 7, server 6)

$ pgrep tmux
3429
$ /proc/3429/exe attach

original post on Google Plus - https://plus.google.com/110139418387705691470/posts/BebrBSXMkBp

Christian
  • 103
  • 3
kanap008
  • 2,599
  • 2
  • 10
  • 3
  • 2
    This looked so cool! But alas, in my debian squeeze -> jessie upgrade (with a temporary stop on wheezy), I got: `tmux at` == `no sessions`. `/var/run/tmux/tmux-0/default` existed, so I tried: `tmux -S /var/run/tmux/tmux-0/default at` == `protocol version mismatch (client 8, server 6)`. Now `/proc/$(pgrep tmux)/exe` == `/proc/2534/exe: Permission denied` and `ls -l /proc/$(pgrep tmux)/exe` == `/proc/2534/exe -> /usr/bin/tmux (deleted)`. :-( – Peter V. Mørch Apr 23 '15 at 09:33
  • Note, however, that in the [Google Plus post](https://plus.google.com/110139418387705691470/posts/BebrBSXMkBp) which is referenced, [tmux developer Thomas Adam](http://fvwmwiki.xteddy.org/) writes that he doesn't recommend doing this. – Abbafei May 27 '15 at 14:53
  • I get the problem that the file handle at /proc/4705/exe is a stale file handle. Can I still use this trick? – Ferrybig Jun 06 '15 at 11:01
  • 1
    @PeterV.Mørch The `/proc/$pid/exe` files [aren't regular symlinks](https://unix.stackexchange.com/q/197854); you should be able to use them to invoke the relevant programs even if they've been unlinked. – Blacklight Shining Nov 30 '15 at 04:04
  • @BlacklightShining: Perhaps I "should" be able to use them. But I did in actual fact really get the messages I described. I have no idea why and have since moved on with my life... ;-) – Peter V. Mørch Nov 30 '15 at 10:09
  • 1
    `pgrep -o tmux` gives the (single) pid of the oldest running tmux, presumably the one with the session you need, so `/proc/$(pgrep -o tmux)/exe attach` might work better than just running `pgrep tmux` (which can return multiple pids) – Matt Curtis May 26 '17 at 00:14
  • wow it worked like charm, I managed to bring back ridiculously previously attachable but somehow after complaining instance attach again with this method, cheers – JacopKane Feb 02 '19 at 23:04
  • @kanap008, you've just saved me! I had ubuntu upgrade process going in tmux session when I lost it and had no way back due to version mismatch!!! Great technique for potentially many other use cases!!! Can't say thank you enough!!! – Dmitry Shevkoplyas Oct 01 '19 at 14:32
40

This basically tells you, that you already have an (old) tmux-server running and the new tmux can't connect to it because they don't understand each other anymore. Exit all your existing tmux sessions and start a fresh one using the new version and everything should be fine.

Andreas Wiese
  • 10,112
  • 1
  • 32
  • 38
  • Yeah logging out seemed key. For the 1.6 to 1.7 upgrade I feel that logging out/in was the only fix. Subsequent version upgrades only seemed to require me to log out of all the terminal windows. – Michael Durrant Mar 30 '14 at 14:59
  • 10
    Please explain how to exit all tmux-sessions properly if you cannot access them, because tmux is not backward compatible! Killing processes is not what I call exiting, this is more like a massacre. ;) – Tino Aug 17 '15 at 09:14
  • 3
    I killed my existing tmux session by using `pkill tmux` (after seeking a tmux session with `pgrep tmux`) from a normal terminal. Afterwards, tmux launched/behaved correctly... – temuraru Jan 26 '17 at 10:10
3

kill all tmux process should work as I also encountered this problem.

sudo killall -9 tmux
dli
  • 131
  • 2
2

This perhaps isn't ideal for you, but I created a chroot, and ran tmux from inside it:

sudo -i
debootstrap stable /chroot
mount -o bind /dev /chroot/dev
mount -o bind /dev/pts /chroot/dev/pts
mount -o bind /sys /chroot/sys
mount -o bind /proc /chroot/proc
chroot /chroot
apt-get install tmux ssh
tmux
ssh user@localhost
apt-get bla bla bla

This ensures that the tmux environment doesn't change during the upgrade

Peter V. Mørch
  • 613
  • 5
  • 11
1

Alternatively, you can pass the -L argument to tmux and have it create a new server group (if you don't want to exit your existing sessions -- I ran into this situation while testing a containerized Ubuntu 18.04 on top of my existing Amazon Linux dev box.)

$ tmux    
protocol version mismatch (client 8, server 7)
$ tmux -L /tmp

[in tmux session, then exit out]

[detached (from session 1)]
$ 

Andrew
  • 111
  • 2
0

In my case it was .bash_profile issue for my user with which tmux session are configured. I have updated the .bash_profile for my user like below and things started working fine

if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

PATH=$PATH:$HOME/.local/bin:$HOME/bin 
export PATH
chaos
  • 47,463
  • 11
  • 118
  • 144
  • Welcome to the site, and thank you for your contribution. Would you mind editing your post to include some explanation on _why_ this would help solve the protocol version issue? You seem to solve the problem by sourcing the `.bashrc` inside the `.bash_profile` so you likely have tmux-related settings in the `.bashrc`; perhaps you could show those explicitly? – AdminBee Jul 28 '21 at 07:46