Почему я получаю сообщение "не подключиться к серверу" из tmux при попытке перечислить сеансы?

Ответ 1

Попробуйте tmux -L name1 list-session.

Ответ 2

Это происходит со мной, когда у меня нет сеансов. Я только начинаю использовать tmux и не понимаю, что если вы перезагрузите компьютер, вы потеряете свои сеансы, которые сначала меня удивили.

Для тех из вас, кто думает так же: Восстановить сеанс tmux после перезагрузки. Краткое описание публикации: Используйте сценарии оболочки для создания сеансов tmux или создайте фантастический отслеживатель истории оболочки.

Ответ 3

TL; DR: Попробуйте отправить SIGUSR1 сигнал на процесс сервера tmux.

В моем случае, примерно через 8 дней бездействия, я не смог повторно подключиться:

$ tmux attach
no sessions

Однако grep для процесса tmux получил мне этот результат:

$ 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

Как указано в @7heo.tk, это указывает на то, что tmux-сервер все еще запущен, но tmux ls выдавал ошибку failed to connect to server: Connection refused. Я подтвердил, что каталог tmp, принадлежащий сеансу tmux, существует, и lsof -p 7139 (pid tmux-сервера) показал, что файл сокета открыт:

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

Я также попытался явно указать -S /tmp/tmux-50440/default на tmux, но это не помогло. Тем не менее, я прочитал на странице man tmux, что отправка SIGUSR1 заставит tmux воссоздать файл сокета, поэтому я попробовал это, и я смог сразу найти сеанс и снова подключиться:

$ kill -s USR1 7139
$ tmux ls
0: 12 windows (created Mon Apr 18 21:17:55 2016) [198x62]

Ответ 4

Это случилось со мной, когда рабочий стол Ubuntu разбился, и мои гном-терминальные окна вышли. Я все еще мог видеть, что процесс tmux запущен (ps aux | grep tmux), но по какой-то причине команды tmux не будут работать, чтобы перечислять существующие сеансы. По-видимому, он не обнаружил существующий сокет Unix в процессе работы tmux. Исправление в этом сценарии - найти существующий сокет Unix и указать его в tmux с помощью флага -S; здесь как:

Вы можете найти PID вашего все еще работающего процесса tmux следующим образом:

ps -p $(pidof tmux)

Теперь возьмите свой PID (в моем случае, 6876) и запустите его, чтобы отобразить все открытые сокеты Unix:

sudo lsof -Uap 6876

Надеюсь, вы увидите вывод следующим образом:

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

Теперь вы можете указать, что существующий сокет Unix для вашей команды tmux (с использованием флага -S), и вы должны иметь возможность перечислить сеансы и правильно прикрепить:

tmux -S /tmp/tmux-1000/default list-sessions
tmux -S /tmp/tmux-1000/default attach -t 0

Ответ 5

Вы действительно получите эту ошибку, если сеанс не открыт. Если сеансов нет, нет сервера tmux, поэтому он не может подключиться к нему.

С опцией -L вы изменяете имя сокета, которое использует сервер tmux, это не способ назвать ваши сеансы. Вам лучше использовать следующие команды:

tmux new -s name1
tmux new -s name2

Они создадут 2 сеанса на сервере с именем сокета по умолчанию. Теперь вы можете сделать:

$ 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)

И вы увидите все сеансы, выполняемые на сервере в сокете по умолчанию. Вы можете подключить один из них, используя:

tmux attach -d -s name1

-s указывает имя сеанса
-d будет отсоединять его от предыдущего клиента (если он подключен)

Вы также можете переключаться между сеансами внутри tmux с помощью команды choose-tree, которая по умолчанию назначается нажатием клавиши C-s (префикс key + s). Это то, что я обычно делаю.

Ответ 6

У вас может быть ошибка в .tmux.conf. У меня была эта проблема, пока я не вытащил эту строку из моего .tmux.conf:

set-window-option -g xterm-keys on

Вы также можете попробовать tmux -v, а затем посмотреть журналы, которые он печатает.

Ответ 7

Я использовал другую программу внутри tmux (reattach-to-user-namespace), и я получал эту ошибку при переключении компьютеров, потому что пространство для повторного подключения к пользователю не было установлено. Исправить было просто запустить brew install reattach-to-user-namespace.

Ответ 8

Одним из простых исправлений является удаление файлов tmp, оставленных сервером tmux, например, путем выполнения $ rm -rf /tmp/tmux-xxx/.

Ответ 9

Способ TMUX(1) заключается в том, что клиентский процесс (tmux) подключается к серверному процессу (tmux тоже, но не привязан к TTY), как показано ниже: ps output:

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

Это показывает, что клиент фактически запускается перед сервером (можно предположить, что он его разворачивает).

После отсоединения/повторного присоединения, команда ps выводит:

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

Это показывает tmux-клиент как tmux attach, поэтому его немного легче понять.

Теперь, если мы посмотрим на вывод pstree в обоих случаях, мы получим в обоих случаях (игнорируя изменение pid для tmux attach):

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

Ясно, что команды, набранные (pstree в этом случае) в клиентском процессе (PID 19229), выполняются одним сервером (PID 19231), что позволяет им продолжать без SIGHUP в случае потери клиентского терминала (например, через ssh).

Теперь, на вопрос О. П. спросил: что происходит в случае, когда tmux возвращает failed to connect to server: Connection refused, является то, что серверный процесс (pid 19231 в нашем случае) недоступен, независимо от причины (может быть, потому что серверный процесс умер, а также потому, что пользователь, выполняющий клиент tmux, не имеет прав доступа к сокету tmux и т.д.)

Решение в этом случае равно grep для процессов tmux (например, через ps) и молюсь, чтобы вы не получили эту ошибку, потому что сервер умер (поэтому вы можете присоединить к нему используя lsof, чтобы узнать, какие сокеты он слушает). В противном случае невозможно подключиться к серверу, так как оно мертво, как после перезагрузки.

TL; DR:

Эта ошибка может быть задана по нескольким причинам: от ошибки до критического сбоя (программа умерла). Вкратце, используйте имеющиеся в вашем распоряжении инструменты UNIX, чтобы определить, какой сокет использует tmux, если он все еще работает (должно быть как минимум два процесса, если у вас работает клиент tmux - это происходит после вызова tmux или tmux attach из оболочки), и, таким образом, если вы потеряли сеанс или нет.

Примечание. Как указывалось в других ответах, если причиной появления этой ошибки является ошибка сокета, вы можете использовать флаг -L, чтобы сообщить tmux использовать определенный сокет.

Ответ 10

Это может произойти, если вы или любой процесс очистки удалите файлы в /tmp/*. Все ваши данные сеанса теряются, если вы не можете восстановить эти файлы. Убивать все экземпляры tmux и перезапускать, это единственный вариант, к сожалению.