38

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
mhermans
  • 1,070
  • 1
  • 9
  • 10

4 Answers4

59

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
mhermans
  • 1,070
  • 1
  • 9
  • 10
  • 1
    I am using `byobu`, which uses `tmux` as a backend, and this worked for me after I accidentally deleted the socket from `/tmp/tmux-`. Thanks! – Nicu Stiurca Aug 20 '15 at 03:44
  • if you know the PID of tmux process, you can use `kill -10 ` or `kill -SIGUSR1 ` 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
  • 3
    You can also use `pkill -10 tmux` to directly send `SIGUSR1` to all tmux process – itamar kanter May 02 '22 at 05:05
  • @itamarkanter thank you! Your version worked for me – Ciprian Tomoiagă Jun 03 '22 at 12:27
10

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.

poige
  • 6,195
  • 2
  • 30
  • 57
  • `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 02:31
  • The first command results in a "no sessions" response. `lsof -v` [output](http://pastie.org/4105235). – mhermans Jun 17 '12 at 22:11
  • `lsof` as given in my answer, dude. :) – poige Jun 18 '12 at 02:31
  • @mhermans, I meant lsof-version of my answer, we don't need its software version. :) – poige Jun 18 '12 at 03:40
  • I misunderstood. See [output](http://pastie.org/4108425). – mhermans Jun 18 '12 at 13:11
  • @mhermans, and where's `awk` part? ) – poige Jun 18 '12 at 15:00
  • @mhermans, also, it's rather too short. Can you manage to run lsof part with root creds? Don't forget to pipe through awk anyway. ;-) – poige Jun 18 '12 at 15:07
  • I appreciate your help, but I don't understand what you are getting at. Why would the `awk` filter help if there are only four results? In fact, the `awk` filter does not return a single hit on the complete `lsof` output. And in any case, I do not have root access. – mhermans Jun 19 '12 at 06:25
  • @mhermans, 4 lines is what that exactly worries me. – poige Jun 19 '12 at 06:32
  • @mhermans, if you'd like you may contact me (see profile for info). It's strange case, so I'm interested a bit. :) – poige Jun 19 '12 at 06:49
3

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)

Jordan Gee
  • 131
  • 3
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.