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)?
[<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="a2cfcac7d0cfc3ccd1e2d5c7c0919396">[email protected]</a> ~]$ 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: <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="7d1015180f101c130e3d0d090e">[email protected]</a>/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
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
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
Method 2
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.
Method 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)
Method 4
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.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0