tmux и screen: работа с сессиями на удалённом сервере

Почему обрыв SSH-соединения обычно означает потерю процесса

Работа с удалённым сервером почти всегда проходит через SSH-соединение, и это соединение по своей природе нестабильно: обрывы случаются из-за перезагрузки роутера дома, временных проблем с сетью, перехода ноутбука в спящий режим или банального закрытия окна терминала по ошибке. Проблема в том, что по умолчанию любой процесс, запущенный внутри такой сессии, тесно связан с её жизненным циклом.

Когда SSH-сессия завершается (штатно или аварийно), операционная система отправляет всем дочерним процессам этой сессии сигнал SIGHUP — исторически он означал именно "hangup", обрыв телефонной линии в эпоху терминалов, подключённых через модем. Процесс, не настроенный на игнорирование этого сигнала, немедленно завершается вместе с сессией, вне зависимости от того, насколько важной была его работа и сколько времени уже было потрачено на её выполнение.

Это особенно болезненно для длительных задач: миграция большой базы данных, синхронизация файлов rsync с удалённого хранилища, компиляция крупного проекта или обучение модели могут занимать часы, и потерять весь прогресс из-за случайного разрыва домашнего интернет-соединения — крайне неприятный опыт, знакомый почти каждому, кто хоть раз администрировал сервер удалённо без защиты от этой проблемы.

Решение — не полагаться на стабильность самого SSH-соединения, а вынести долгоживущий процесс в отдельную виртуальную сессию терминала, которая продолжает существовать на сервере независимо от того, подключены вы к ней прямо сейчас или нет. Именно эту задачу решают tmux и screen — мультиплексоры терминала, ставшие стандартным инструментом для любой работы с удалённым сервером дольше пары минут.

Мультиплексор терминала: базовая идея

tmux и screen оба реализуют одну и ту же концепцию: программа-мультиплексор запускается на сервере как самостоятельный процесс, создающий одну или несколько виртуальных сессий терминала. SSH-клиент подключается к этому процессу, как к обычной программе, и всё, что происходит внутри такой сессии — запущенные команды, их вывод, история прокрутки — существует независимо от конкретного SSH-соединения, через которое к ней подключились.

Ключевое действие, которое даёт мультиплексору терминала практическую ценность, — отключение (detach) без завершения сессии. В отличие от закрытия окна терминала, при котором сессия SSH и всё, что внутри неё выполнялось, полностью прекращает существование, отключение от tmux или screen оставляет саму сессию и все запущенные в ней процессы работать на сервере как ни в чём не бывало — просто без активного подключённого клиента, наблюдающего за экраном в реальном времени.

Позже, из того же или из совершенно другого клиента, можно подключиться (attach) к той же самой сессии и увидеть её ровно в том состоянии, в каком она была оставлена, — включая весь накопленный за время отсутствия вывод команд. Это принципиально отличается от простого запуска процесса в фоне через амперсанд (&) в обычном bash: там процесс продолжает работать, но интерактивный доступ к его терминалу и истории вывода теряется безвозвратно.

Дополнительное практическое преимущество — возможность делить одну и ту же сессию между несколькими подключёнными одновременно клиентами, что удобно для совместной отладки проблемы на сервере: два администратора подключаются к одной tmux-сессии с разных машин и видят один и тот же экран в реальном времени, как при демонстрации экрана, но без дополнительного ПО для скринкастинга.

tmux: базовые команды и структура

Работа с tmux строится вокруг понятия сессии (session), внутри которой может быть несколько окон (window, аналог вкладок), а каждое окно, в свою очередь, можно разделить на несколько панелей (pane) для одновременного отображения нескольких терминалов на одном экране.

tmux new -s deploy
tmux ls
tmux attach -t deploy
tmux kill-session -t deploy

Флаг -s задаёт осмысленное имя сессии вместо автоматически присваиваемого числового идентификатора — это особенно полезно, если на сервере одновременно работает несколько администраторов или если планируется вернуться к сессии через продолжительное время, когда числовой номер вроде "0" уже ничего не скажет о её содержимом. Команда tmux ls показывает список всех активных сессий на сервере с их именами и числом открытых окон в каждой.

Все команды управления внутри tmux вызываются через сочетание клавиш-префикса, по умолчанию это Ctrl+b, после которого нажимается вторая клавиша, определяющая конкретное действие. Отключение от сессии без её завершения выполняется префиксом и клавишей d (detach) — именно эта команда, а не закрытие окна терминала, оставляет всё содержимое сессии работать на сервере.

Ctrl+b d       # отключиться от сессии, оставив её работать
Ctrl+b c       # создать новое окно
Ctrl+b n       # переключиться на следующее окно
Ctrl+b p       # переключиться на предыдущее окно
Ctrl+b %       # разделить панель по вертикали
Ctrl+b "       # разделить панель по горизонтали
Ctrl+b стрелки # переключение между панелями

Разделение экрана на панели особенно полезно при одновременном наблюдении за несколькими потоками информации — например, в одной панели запущен tail -f для просмотра логов приложения в реальном времени, в соседней панели идёт мониторинг нагрузки через htop, а в третьей выполняются собственно административные команды, и переключение между ними занимает долю секунды без необходимости открывать отдельные окна терминала или SSH-сессии.

screen: базовые команды и когда он предпочтительнее

screen — предшественник tmux по идее, но всё ещё широко используемый инструмент, в первую очередь благодаря тому, что он предустановлен практически на любом Unix-подобном сервере из коробки, тогда как tmux иногда приходится доустанавливать отдельно, что критично в ситуациях, когда доступ к пакетному менеджеру ограничен или сервер изолирован от интернета.

screen -S deploy
screen -ls
screen -r deploy
Ctrl+a d       # отключиться от сессии
Ctrl+a c       # создать новое окно

Синтаксис screen местами похож на tmux, но со своими особенностями: сочетание-префикс по умолчанию — Ctrl+a вместо Ctrl+b, а флаг для именованной сессии тот же -S. Список активных сессий выводится командой screen -ls, а подключение к конкретной сессии по имени — screen -r с указанием этого имени.

Практическая разница между screen и tmux в повседневной работе постепенно сокращается по мере распространения tmux, но у screen остаётся одно устойчивое преимущество: гарантированное наличие на сервере без необходимости установки дополнительных пакетов. Для быстрой разовой задачи на чужом или временном сервере, где неизвестно, будет ли разрешена установка ПО, screen часто оказывается единственным доступным вариантом мультиплексора терминала прямо из коробки.

У screen заметно менее гибкая по сравнению с tmux система разделения экрана на панели, более скудная документация встроенной справки и меньше возможностей для тонкой настройки через конфигурационный файл — по этим причинам для сервера, которым предстоит пользоваться регулярно и где установка дополнительного пакета не проблема, практика в большинстве случаев склоняется в пользу tmux, оставляя screen как резервный вариант знаний "на всякий случай".

Реальный сценарий: длительная задача с отключением и повторным подключением

Рассмотрим типичный практический случай: нужно перенести большой каталог с файлами (несколько десятков гигабайт) на другой сервер через rsync, и операция займёт по оценке час-полтора — заведомо больше, чем можно гарантированно удерживать активное SSH-соединение без единого обрыва.

ssh user@server.example.ru
tmux new -s rsync-transfer
rsync -avz --progress /var/www/uploads/ user@remote-server.example.ru:/var/www/uploads/

После запуска команды rsync внутри tmux-сессии можно спокойно отключиться от неё сочетанием Ctrl+b, затем d, не дожидаясь завершения передачи, — сама передача продолжит выполняться на сервере, полностью независимо от того, подключён ли к ней сейчас какой-либо клиент. После этого можно закрыть ноутбук, переключиться на другую задачу или вовсе временно потерять доступ к интернету — процесс на сервере это никак не затронет.

ssh user@server.example.ru
tmux ls
tmux attach -t rsync-transfer

При повторном подключении к серверу (пусть даже спустя несколько часов, с совершенно другого устройства) команда tmux attach вернёт полный доступ к той же сессии — на экране будет виден прогресс rsync ровно так, как если бы отключения никогда не было, включая весь вывод, накопившийся за время отсутствия наблюдателя. Если передача уже завершилась, в сессии будет виден финальный отчёт о результатах, а сама сессия останется доступной для повторного использования или для явного закрытия командой tmux kill-session, если больше не нужна.

Тот же подход применим к любой длительной операции: развёртыванию приложения, компиляции проекта из исходников, полному бэкапу базы данных мимо потоковых инструментов или обучению модели машинного обучения — общий принцип один и тот же: запускать долгоживущий процесс внутри именованной tmux-сессии, а не напрямую в интерактивной SSH-сессии, срок жизни которой полностью зависит от стабильности сетевого соединения администратора.

Копирование текста и работа с историей вывода

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

Ctrl+b [       # войти в режим копирования (copy mode)
Пробел         # начать выделение (в стандартной раскладке клавиш)
Enter          # скопировать выделенное в буфер tmux
Ctrl+b ]       # вставить скопированный текст

Внутри режима копирования можно перемещаться по истории вывода клавишами со стрелками (или в стиле vi, если tmux настроен на соответствующую раскладку через set -g mode-keys vi в конфигурационном файле), искать текст, а выделение и копирование выполняются полностью с клавиатуры, без зависимости от того, насколько корректно конкретный терминальный эмулятор передаёт события мыши в удалённую SSH-сессию.

Многие современные терминальные эмуляторы (iTerm2, Windows Terminal, большинство эмуляторов на Linux) при этом поддерживают выделение текста мышью с зажатой клавишей Shift, которое обходит перехват событий мыши самим tmux и работает как в обычном, не мультиплексированном терминале, — это часто оказывается быстрее для разового копирования короткого фрагмента текста, тогда как встроенный режим копирования tmux удобнее для навигации по длинной истории вывода и для точного посимвольного выделения.

Буфер обмена самого tmux (в который попадает текст, скопированный через copy mode) не синхронизирован с системным буфером обмена операционной системы по умолчанию — для такой синхронизации на Linux обычно требуется дополнительная настройка через xclip или аналогичную утилиту, тогда как на macOS и в современных версиях Windows Terminal интеграция с системным буфером зачастую работает из коробки без дополнительных действий.

Настройка tmux через конфигурационный файл

Поведение tmux по умолчанию можно существенно изменить через конфигурационный файл ~/.tmux.conf, который читается при запуске каждой новой сессии tmux. Это особенно полезно для смены неудобного по умолчанию префикса Ctrl+b на более распространённый на практике Ctrl+a (тот же, что использует screen, что упрощает переключение между привычками, если приходится работать с обеими программами) и для включения ряда практичных мелочей.

set -g prefix C-a
unbind C-b
bind C-a send-prefix

set -g mouse on
set -g history-limit 10000
set -g mode-keys vi
set -g status-bg colour235
set -g status-fg white

Директива set -g mouse on включает поддержку мыши внутри tmux — переключение между панелями кликом, изменение размера панели перетаскиванием границы и прокрутку истории вывода колесом мыши, что заметно снижает порог входа для тех, кто ещё не запомнил все сочетания клавиш наизусть. history-limit увеличивает размер буфера прокрутки для каждой панели — значение по умолчанию (обычно 2000 строк) может оказаться маленьким для панели с активным потоком логов.

Строка status-bg и status-fg настраивают внешний вид строки статуса внизу экрана tmux — казалось бы, косметическая деталь, но при работе одновременно с несколькими серверами разный цвет строки статуса в конфигурации каждого сервера служит быстрым визуальным индикатором того, к какому именно серверу подключена текущая сессия, что снижает риск случайно выполнить деструктивную команду не на том сервере, перепутав окна терминала.

После изменения конфигурационного файла для уже запущенной сессии tmux новые настройки применяются либо через полный перезапуск tmux, либо командой tmux source-file ~/.tmux.conf, введённой прямо внутри существующей сессии, — второй вариант удобнее, поскольку не требует закрывать уже открытые окна и панели с работающими в них процессами.

Типичные ошибки при работе с tmux и screen

Закрытие окна терминала (или SSH-клиента) вместо явного отключения через Ctrl+b d — в некоторых конфигурациях терминала это действительно оставляет tmux-сессию работать на сервере, поскольку сама сессия существует независимо от клиентского окна, но полагаться на это поведение не стоит: правильная привычка — всегда отключаться от сессии явной командой, а не просто закрывать окно и надеяться на лучшее.

Забытые старые сессии, накопившиеся за месяцы работы с сервером, — каждая неиспользуемая, но не закрытая сессия tmux продолжает занимать память процессом самого мультиплексора и создаёт путаницу при просмотре списка через tmux ls, особенно если несколько администраторов создавали безымянные сессии с автоматически присвоенными числовыми именами.

Запуск критически важной длительной задачи напрямую в обычной SSH-сессии без tmux или screen "на этот раз обойдётся" — обрыв соединения непредсказуем по своей природе, и именно тот единственный раз, когда решили не заворачивать команду в tmux ради экономии нескольких секунд, статистически чаще всего и оказывается тем разом, когда соединение обрывается посреди выполнения.

Путаница между несколькими одновременно открытыми tmux-сессиями с похожими именами или без имён вовсе — выполнение команды не в той сессии, что предполагалось, особенно опасно, если одна из сессий подключена к продакшн-серверу, а другая — к тестовому окружению; осмысленное именование сессий через флаг -s при создании снижает этот риск почти до нуля.

Чек-лист и итог: сессии как страховка от обрыва соединения

Шаг 1. Перед запуском любой задачи дольше пары минут — создайте именованную tmux-сессию: tmux new -s имя_задачи, а не запускайте команду напрямую в обычной SSH-сессии.

Шаг 2. Отключайтесь от сессии явным сочетанием Ctrl+b (или Ctrl+a для screen), затем d — не полагайтесь на закрытие окна терминала.

Шаг 3. Периодически проверяйте список активных сессий через tmux ls и закрывайте те, что больше не нужны, через tmux kill-session -t имя.

Шаг 4. Используйте разделение на панели для одновременного наблюдения за логами, мониторингом нагрузки и выполнением команд в рамках одной задачи.

Шаг 5. Настройте ~/.tmux.conf под удобный лично вам префикс, поддержку мыши и увеличенный лимит истории прокрутки — это окупается уже через несколько дней активной работы.

Шаг 6. Помните, что сессии tmux и screen не переживают перезагрузку сервера — для задач, которые должны продолжать работать после перезапуска, используйте systemd-службы, а не мультиплексор терминала.

Разница между потерянным часом работы из-за случайного обрыва соединения и спокойным переподключением к той же самой задаче через несколько часов часто сводится к одной короткой команде, введённой в самом начале работы. tmux и screen не решают проблему нестабильности сети сами по себе, но полностью убирают её последствия для процессов, запущенных на сервере, — а привычка оборачивать в сессию любую задачу длиннее нескольких минут довольно быстро становится автоматической.