80

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
  • 65,642
Michael Durrant
  • 42,013

6 Answers6

250

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
kanap008
  • 2,609
  • 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 which is referenced, tmux developer Thomas Adam 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; 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,400
  • 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

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
  • 633
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
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
  • 48,171
Mohan Krishna
  • 1
  • 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