13

I have had a tmux session running for a while, and I can see it's running using pstree:

systemd─┬─accounts-daemon───2*[{accounts-daemon}]
        ├─2*[agetty]
        ├─containerd───11*[{containerd}]
        ├─cron
        ├─dbus-daemon
        ├─4*[dd]
        ├─dockerd───12*[{dockerd}]
        ├─fail2ban-server───2*[{fail2ban-server}]
        ├─irqbalance───{irqbalance}
        ├─networkd-dispat
        ├─polkitd───2*[{polkitd}]
        ├─qemu-ga
        ├─rsyslogd───3*[{rsyslogd}]
        ├─ssh-agent
        ├─sshd───sshd───sshd───bash───pstree
        ├─systemd───(sd-pam)
        ├─systemd-journal
        ├─systemd-logind
        ├─systemd-network
        ├─systemd-resolve
        ├─systemd-timesyn───{systemd-timesyn}
        ├─systemd-udevd
        ├─tmux: server─┬─bash───find_cli
        │              └─3*[bash]
        └─unattended-upgr───{unattended-upgr}

(it's down the bottom there)

However, tmux itself insists there are no sessions:

$ tmux attach
no sessions
$ tmux ls
no server running on /tmp/tmux-1000/default

Is there any way to recover a tmux session in this situation?

5
  • 1
    Is it actually running as the current user, or as some other user?
    – Kusalananda
    Apr 25, 2020 at 12:13
  • Or with a non-default socket. See man 1 tmux, options -L and -S. Can it be the case? On the other hand, if you started a server in a non-default way, you would probably know. Apr 25, 2020 at 12:31
  • Looks like that tmux is being run by another user on the system. See if any other user is logged into the system. use w
    – GMaster
    Apr 25, 2020 at 13:52
  • @GMaster They might have started tmux as root, disconnected from it, and forgotten about it.
    – Kusalananda
    Apr 25, 2020 at 18:00
  • Yes it must be running as me (ubuntu), because ps -aux returns ubuntu 23508 0.8 0.0 19116 7696 ? Ss Mar02 673:09 tmux
    – Migwell
    Apr 26, 2020 at 14:00

2 Answers 2

26

If the socket has been removed you should be able to make tmux recreate it with pkill -USR1 tmux.

8
  • 1
    I still have a process running under that tmux session which I can't afford to cancel. Will this affect the child process?
    – Migwell
    Apr 26, 2020 at 14:01
  • 1
    It shouldn't do. Apr 26, 2020 at 15:12
  • 2
    I don't know why this works, but it does. I was able to tmux attach immediately after running that command.
    – Migwell
    Apr 27, 2020 at 4:23
  • 1
    Something removed your tmux socket in /tmp and sending this signal to the tmux server asks it to create it again. Apr 27, 2020 at 5:46
  • 4
    Ah, so USR1 is a program-defined signal that tmux uses as a signal to recreate the socket. pkill here isn't being used to kill the process, but rather send USR1 to tmux.
    – Migwell
    Apr 27, 2020 at 5:51
0

If ps or other process information commands show that tmux is still running but doesn't respond properly to the tmux attach command, you might be able to make tmux interactive again by sending a SIGUSR1 signal to the tmux server.

This can be done, as mentioned in the answer above, by using the pkill -USR1 tmux command. You can then run the tmux attach command again to see if you can now interact with tmux.

An alternative to the machine-gun method of using pkill is to use a specific PID number with kill. The command template would be quite similar to the pkill method save for the use of a PID number rather than a program name pattern. Thus your command might look like the following:

$ kill -USR1 NNNN

You can get the NNNN by carefully reading the output of ps ax | grep tmux. This assumes you have several tmux instances running. Otherwise (i.e. if you're running only one tmux instance), it's indeed easier to pkill tmux.

As a side note, I find both pkill and killall to be pretty dangerous, especially when used as root.

2

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .