72

Here's what's happening to me: I start tmux sessions using tmux -L name1, tmux -L name2; then I detatch them using ctrl+B+d. Then I try to get a list of the currently running sessions on my computer. However, when I run tmux ls, I get an error message: 

failed to connect to server: Connection refused

Is this a bug? I'm familiar with screen; I regard screen -ls as a very useful function since I might start a session and leave it running for weeks before the next time I attach to it. Because of this, the ability to list current running tmux sessions is quite important for me. Why does tmux ls return a "connection refused" error when I know tmux is running?

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
thinke365
  • 1,305
  • 3
  • 14
  • 22

11 Answers11

81

TL;DR: Try sending SIGUSR1 signal to the tmux server process.

In my case, after about 8 days of inactivity, I was not able to reattach:

$ tmux attach
no sessions

However, a grep for tmux process got me this output:

$ ps -aef | fgrep -i tmux
hari     7139     1  1  2016 ?        2-20:32:31 tmux
hari    25943 25113  0 22:00 pts/0    00:00:00 fgrep --color=auto -i tmux

As suggested by @7heo.tk, this indicates that tmux server is still running, but tmux ls was giving failed to connect to server: Connection refused error. I verified that the tmp directory that belonged to the tmux session existed and lsof -p 7139 (the pid of tmux server) showed that the socket file is open:

COMMAND  PID  USER   FD   TYPE             DEVICE SIZE/OFF       NODE NAME
tmux    7139 hari    5u  unix 0x0000000000000000      0t0 1712879255 /tmp/tmux-50440/default

I also tried explicitly specifying the -S /tmp/tmux-50440/default to tmux but it didn't help. However, I read in the tmux man page that sending SIGUSR1 would make tmux recreate the socket file, so I tried that and I was able to immediately find the session and reattach:

$ kill -s USR1 7139
$ tmux ls
0: 12 windows (created Mon Apr 18 21:17:55 2016) [198x62]
haridsv
  • 9,065
  • 4
  • 62
  • 65
  • 6
    This is the only thing that worked for me. I did the foolish thing of performing an `rm -rf tmp/*` which removed the tmux socket file. I will definitely remeber this trick. – Sudo Bash Feb 14 '17 at 22:50
  • 1
    This solved my problem too: I had changed an idiotic default setting of $TMP, which meant the tmux socket was in the wrong place. – user2475529 Jun 21 '17 at 18:56
  • 1
    Thank you for your answer, this solved the problem for me too. Could you maybe elaborate on what's happening here and why this fix is necessary? – Harpe Sep 26 '17 at 08:32
  • @Harpe I don't know, probably a tmux bug that is not easily reproducible. – haridsv Sep 27 '17 at 03:51
  • the easier one-liner to accomplish this at once would be: `pkill -USR1 -xf tmux` (at least if you started the tmux server with its plain `tmux` command.) – DJCrashdummy Aug 05 '19 at 06:22
  • or possibly `pkill -USR1 -o tmux` should also work and even if you didn't use just the plain `tmux` command to start its server. – DJCrashdummy Aug 05 '19 at 06:41
  • This is the only thing that worked!! Thanks lot @haridsv – Avtar Sohi Aug 07 '20 at 01:42
  • Which of the commands in your answer is it that sends a `SIGUSR1` signal to the tmux server process? – HelloGoodbye Jun 03 '22 at 15:56
  • `kill -s USR1` is the one that sends the `SIGUSR1` signal to the process. – haridsv Jun 05 '22 at 13:00
34

This happens to me when I do not have any sessions running. I'm just starting to use tmux and didn't realize that if you restart your computer you lose your sessions which surprised me at first.

For those of you who are thinking the same thing: Restore tmux session after reboot. A summary of the post: Use shell scripts to build your tmux sessions or create a fancy shell history tracker.

Community
  • 1
  • 1
Nathan
  • 1,762
  • 1
  • 20
  • 30
  • 12
    FYI: tmux sessions don't get saved after reboot because they are simply background processes that will end when the computer turns off. – Nathan May 19 '13 at 18:22
  • not really an accurate answer because the OP said nothing about a reboot, but nevertheless a nice link to a good question very with useful ideas & links. – DJCrashdummy Aug 02 '19 at 08:12
  • I mentioned the reboot @DJCrashdummy because that's how I ran into the problem. Maybe the OP rebooted or maybe they didn't. Answers on SO don't have to be accurate. The hope is to be helpful to the greater community. – Nathan Aug 06 '19 at 16:44
19

You get this error indeed if there are no session open. If there are no sessions open there is no tmux server running so it can't connect to it.

With the -L option, you change the socket name the tmux server uses, it's not a way to name your sessions. You better use the following commands:

tmux new -s name1
tmux new -s name2

These will create 2 sessions on a server with the default socket name. Now you can do:

$ tmux ls
name1: 1 windows (created Mon Sep 22 10:34:40 2014) [158x40] (attached)
name2: 1 windows (created Mon Sep 22 10:34:43 2014) [158x40] (attached)

And you see all the sessions running on the server on the default socket. You can reattach one of them using:

tmux attach -d -s name1

-s specifies the name of the session
-d will detach it from it's previous client (if it is attached)

You can also switch between sessions inside tmux with the choose-tree command which by default is assigned to the keystroke C-s (prefix key + s). This is what I usually do.

gitaarik
  • 42,736
  • 12
  • 98
  • 105
19

This happened to me when the Ubuntu desktop crashed and my gnome-terminal windows exited. I could still see the tmux process was running (ps aux | grep tmux) but for some reason tmux commands would not work to list the existing sessions. Apparently it wasn't finding the existing Unix socket of the still-running tmux process. The fix in this scenario is to locate the existing Unix socket and specify that to tmux using the -S flag; here's how:

You can find the PID of your still-running tmux process with this:

ps -p $(pidof tmux)

Now take your PID (in my case, 6876) and run this to list any open Unix sockets:

sudo lsof -Uap 6876

Hopefully you see output like this:

COMMAND  PID USER   FD   TYPE             DEVICE SIZE/OFF   NODE NAME
tmux    6876  abe    3u  unix 0x0000000000000000      0t0 408477 socket
tmux    6876  abe    4u  unix 0x0000000000000000      0t0 408478 socket
tmux    6876  abe    6u  unix 0x0000000000000000      0t0 408479 /tmp/tmux-1000/default

Now you can specify that existing Unix socket to your tmux command (using the -S flag), and you should be able to list-sessions and attach properly:

tmux -S /tmp/tmux-1000/default list-sessions
tmux -S /tmp/tmux-1000/default attach -t 0
Abe Voelker
  • 30,124
  • 14
  • 81
  • 98
9

You may have an error in your .tmux.conf. I had this problem until i took out this line from my .tmux.conf:

set-window-option -g xterm-keys on

You could also try tmux -v and then look at the logs it prints.

Rose Perrone
  • 61,572
  • 58
  • 208
  • 243
6

One easy fix is to delete the tmp files left by the tmux server, for example, by doing $ rm -rf /tmp/tmux-xxx/.

Shumin Guo
  • 184
  • 1
  • 3
  • 11
  • Thanks, this was the solution for me. The next step is just to create a new session with `tmux new -s $session_name` and that's all. – Carlos A. Ortiz Aug 18 '17 at 22:11
6

The way TMUX(1) works is by having a client process (tmux) connect to a server process (tmux too, but not attached to a TTY), as shown in the following ps output:

  PID TTY      STAT   TIME COMMAND
19229 pts/1    S+     0:00 tmux
19231 ?        Ss     0:00 tmux

That shows that the client actually starts before the server (one could assume it forks it).

After detach/re-attach, the same ps command outputs:

  PID TTY      STAT   TIME COMMAND
19231 ?        Ss     0:00 tmux
19290 pts/1    S+     0:00 tmux attach

This shows the tmux client as tmux attach, thus being a bit easier to understand.

Now, if we look at the output of pstree in both of the above cases, we get in both cases (ignoring the pid change for tmux attach):

pstree -p
init(1)─┬─acpid(1824)
        ├─cron(1859)
        ⋮
        ├─sh(14146)───tmux(19229)
        └─tmux(19231)───sh(19233)───pstree(19234)

Clearly showing that the commands typed (pstree in this case) in the client process (PID 19229) get executed by the server one (PID 19231), thus allowing them to continue without SIGHUP in the event where the client terminal is lost (over ssh, for example).

Now, to the question OP asked: what happens in the case where tmux returns failed to connect to server: Connection refused is that the server process (pid 19231 in our case) is unreachable, whatever the reason (it can be because the server process died; but also because the user executing the tmux client doesn't have the permissions to access the tmux socket, etc.)

The solution in that case is to grep for the tmux processes (via ps for example), and pray that you didn't get this error because the server died (so you can attach to it by using lsof to get what sockets it listens to). Otherwise, there is no way to attach to the server, as it is as dead as after a reboot.

TL;DR:

This error can be given for multiple reasons, ranging from bug to critical failure (program died). In a nutshell, use the UNIX tools at your disposal to determine what socket does tmux use, if it is still running (there should be at least two processes if you have the tmux client running - that happens after invoking tmux or tmux attach from the shell) and thus if you lost your session or not.

Note: as other answers pointed out, if the reason for this error to be shown is a socket error, you can use the -L flag to tell tmux to use a specific socket.

7heo.tk
  • 1,074
  • 12
  • 23
3

This may happen if you or any cleaning process delete files in /tmp/*. All your sessions data are lost if you can't recover those files. Killing all tmux instances and restart it is the only choice left, unfortunately.

Pierre Maoui
  • 5,976
  • 2
  • 27
  • 28
2

I was using another program inside of tmux (reattach-to-user-namespace), and I was getting this error when I switched computers because reattach-to-user-namespace was not installed. The fix was to simply run brew install reattach-to-user-namespace.

akofink
  • 689
  • 5
  • 8
0

This happened to me because I ran tmux with another user (was root), and I tried to list sessions with my normal user.. So you might want to check the user with which you ran your tmux first. To do so:

$ ps -aef | fgrep -i tmux
root     7139     1  1  2016 ?        2-20:32:31 tmux
centos    25943 25113  0 22:00 pts/0    00:00:00 fgrep --color=auto -i tmux

See the username in the first column: here it's root

Killian G.
  • 370
  • 2
  • 15
-4

Try tmux -L name1 list-session.

Lars Kotthoff
  • 107,425
  • 16
  • 204
  • 204
  • 1
    This command will only list the `name1` session and not `name2`. See [my answer](http://stackoverflow.com/a/25969889/1248175) for a way to list multiple sessions. – gitaarik Sep 22 '14 at 08:48
  • 35
    The **first** word of the question is "Why". That answer doesn't even try to deliver. Plus that command actually failed in my case (however, `tmux -L list-session` magically worked - now I have to dig myself to know why, why not the former, how, etc. So basically I have to answer OP's question for myself). – 7heo.tk May 13 '15 at 08:18
  • 7
    @whyisyoung Unfortunately SO doesn't allow to unvote comments after a few minutes. But your comment is highly misleading. What you are doing with `tmux -L list-session` is to **START A NEW** instance of tmux, with a socket named `list-session`. This is utterly misleading, as the command reads: "use tmux to list the sessions with the flag -L set". You should delete that comment (since you can't edit anymore), given how harmful it is. – 7heo.tk May 13 '15 at 08:47
  • 3
    @7heo.tk Sorry I cannot remember what happened at that time. Then I tried the command `tmux -L list-session`, it indeed start a new **instance**, not **session**. thanks for your comment. – whyisyoung May 14 '15 at 14:18
  • @whyisyoung thank you for your cleanup; it is cool to see that SO's content improves over time. (Unrelated: for the people who read the comments above; I answered OP's question for everyone (not only myself) [here](http://stackoverflow.com/a/30211312)) – 7heo.tk May 15 '15 at 09:13