34

I was trying to re-attach to a long-running tmux session to check up on a python web-application. However tmux attach claims that there is no running session, and ps shows a tmux process (first line), but with a question mark instead of the pts number.

What does this mean---is this tmux session permanently lost, and what could have caused it? Is there still a way to look at the current state of the python process, spawned in the tmux session and running in pts/19 (second line)?

[mhermans@web314 ~]$ ps -ef | grep mhermans
mhermans 16709     1  0 Mar04 ?        00:26:32 tmux
mhermans  8526 16710  0 Mar04 pts/19   00:20:04 python2.7 webapp.py
root      9985  6671  0 10:18 ?        00:00:00 sshd: mhermans [priv]
mhermans 10028  9985  0 10:18 ?        00:00:00 sshd: mhermans@pts/16
mhermans 10030 10028  0 10:18 pts/16   00:00:00 -bash
mhermans 16247 10030  6 10:28 pts/16   00:00:00 ps -ef
mhermans 16276 10030  0 10:28 pts/16   00:00:00 grep mhermans
mhermans 16710 16709  0 Mar04 pts/19   00:00:00 -bash
mhermans 16777 16709  0 Mar04 pts/21   00:00:00 -bash
2
  • What does tmux ls show? – jasonwryan Jun 16 '12 at 9:04
  • "failed to connect to server: Connection refused" – mhermans Jun 16 '12 at 10:31
49

Solution courtesy of the Webfaction-support:

As the process was still running, the issue was a deleted socket, possibly caused by a purged tmp-directory.

According to the tmux mapage:

If the socket is accidentally removed, the SIGUSR1 signal may be sent to the tmux server process to recreate it.

So sending the signal and attaching works:

killall -s SIGUSR1 tmux
tmux attach
2
  • I am using byobu, which uses tmux as a backend, and this worked for me after I accidentally deleted the socket from /tmp/tmux-<pid>. Thanks! – Nicu Stiurca Aug 20 '15 at 3:44
  • if you know the PID of tmux process, you can use kill -10 <PID> or kill -SIGUSR1 <PID> as -SIGUSR1 is -10 . This is useful when you are on a shared server. You don't want to send SIGUSR1 to other users' tmux processes. – Thamme Gowda Sep 23 '20 at 21:01
9

Terminal absence is a sign of detached session. And all your tmux session names can be found thus:

ls $TMP/tmux-$(id -u) or ls /var/run/tmux/tmux-$(id -u)

— this is kinda distro-dependent. Almost distro-independent (and more hardcore) would be:

lsof -n -p 16709 -a -U

where 16709 is the PID of tmux in your listing.

11
  • id -u gives 532 and /tmp/tmux-532 contains a single file "default". How does this help me further? – mhermans Jun 16 '12 at 20:27
  • 1
    Try tmux -S /tmp/tmux-532/default at, but default socket-name should be just ok with tmux at. What does lsof-version say? – poige Jun 17 '12 at 2:31
  • The first command results in a "no sessions" response. lsof -v output. – mhermans Jun 17 '12 at 22:11
  • lsof as given in my answer, dude. :) – poige Jun 18 '12 at 2:31
  • @mhermans, I meant lsof-version of my answer, we don't need its software version. :) – poige Jun 18 '12 at 3:40
1

This is how this earlier answer here helped me (wow!). I was trying to resolve exactly the situation where I'm attached to one Tmux--which I can see in tmux ls, but in ps, I can see also another tmux, which is not listed in tmux ls therefore I cannot attach to it via using its name (tmux attach -t myOldbas)

Here are the full details. Processes:

71358     1849  9617  0 Sep04 pts/29   00:00:00 /bin/bash
71358     2528  9617  0 Aug31 pts/25   00:00:00 /bin/bash
71358     9617     1  0 Aug31 ?        00:08:55 tmux new -s myOld
71358     9618  9617  0 Aug31 pts/20   00:00:00 /bin/bash
71358    20199 33189  0 Sep16 pts/27   00:00:00 vim log
71358    20415 32257  0 Sep16 pts/30   00:00:00 /bin/bash
71358    24735 32257  0 Sep16 pts/33   00:00:00 /bin/bash
71358    32257     1  0 Sep16 ?        00:04:02 tmux new -s myses

Now, the lsof bit is what really helped me--when you do it for both processes, in my case 32257 (the one I can see), and 9617 (the old one)

/usr/sbin/lsof -n -p 32257 -a -U
COMMAND   PID             USER   FD   TYPE             DEVICE SIZE/OFF      NODE NAME
..
tmux    32257 uzer.buzer          7u  unix 0xffff881ff0c73480      0t0 995795763 /tmp/uzer.buzer/tmux-71358/default

However when I used on the old PID , I saw the following

/usr/sbin/lsof -n -p 9617 -a -U

tmux    9617 uzer.buzer          7u  unix 0xffff881ff0c73480      0t0 995795763 /tmp/tmux-71358/default

Notice, how the last socket path is different? Luckily, that's all I needed and then I executed the attach command with an explicit socket:

tmux -S /tmp/tmux-71358/default at

and I was in!! 👍 Attached to my old tmux called myOldbas.
(In reality what probably happened earlier was that I was changing TMP paths/.bashrc and ended up with two tmux sessions)

0

For people who come across this thread at a later date;

If you use sudo to run a script or something, the tmux session is listed under root, not under the user who used sudo, since actions following sudo are performed under root.

To remedy this, either use sudo tmux a, or tmux as root to regain control of your tmux session.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.