Когда нужен терминальный мультиплексор

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

Это удобно для обновления тестовой копии, чтения лога или длительного экспорта, за которым нужно наблюдать. Но мультиплексор сам по себе не управляет автозапуском, рестартом или мониторингом. Для постоянной службы используйте systemd unit; для разовой фоновой команды может подойти другой способ запуска, если сохраняются журналы и понятен статус завершения.

Быстрый сценарий в tmux

Запустите именованную сессию командой tmux new -s import. Внутри выполните нужную команду, затем нажмите Ctrl+B, отпустите клавиши и нажмите D. Клиент отсоединится, но терминальная сессия останется на сервере.

При следующем SSH-входе выполните tmux ls, чтобы увидеть существующие сессии, а затем tmux attach -t import. Если имя занято, сначала выясните, кто использует сессию. Не присоединяйтесь к чужой рабочей консоли без согласования.

Остановите команду штатным способом до закрытия сессии. Для программы, которая завершилась, терминал обычно остается доступным, чтобы прочитать код возврата или сообщение. Удалять сессию стоит только после проверки, что нужная работа завершена.

Тот же порядок в GNU Screen

Если screen -r сообщает, что сессия уже подключена, не удаляйте ее сразу. Проверьте список терминалов и определите, висит ли старое SSH-подключение или сессией пользуется коллега. Screen умеет переподключать текущую сессию, но принудительное отсоединение может оборвать работу другого пользователя.

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

Создайте сессию: screen -S import. Чтобы отсоединиться, нажмите Ctrl+A, затем D; screen оставит сессию свернутой. Список покажет screen -ls, а повторное подключение выполняет screen -r import или выбранный ID сессии.

При недоступной сессии проверьте владельца, имя, статус и то, не подключен ли к ней другой терминал. Удаленная или «мертвая» сессия не обязана означать, что ее процессы работают. Посмотрите список процессов и журнал отдельно.

GNU Screen различает отсоединение и завершение. Отсоединенная сессия доступна для повторного подключения, а выход из последнего shell может завершить окно или всю сессию. Не закрывайте ее, пока не сохранили вывод или не проверили, что команда закончилась.

Что переживает разрыв, а что нет

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

Мультиплексор сохраняет интерактивный терминал, но не обещает, что процесс закончит работу успешно. Если выгружается архив или собирается проект, запишите вывод в файл, следите за свободным местом и проверьте финальный код возврата. Если задача должна переживать перезагрузку узла, заранее выберите сервисный менеджер и настройте автозапуск.

Различайте три события: SSH-клиент отключился, терминальная сессия завершилась и сам процесс аварийно остановился. Это не одно и то же. Screen/tmux помогают только в первом случае, пока живы узел и соответствующая сессия пользователя. Для результата нужны собственные журналы, контрольные суммы, резервные копии или повторный запуск из надежного задания.

Мультиплексор переживает потерю терминала, но не обязательно перезагрузку VPS, остановку процесса или сбой питания. Сессия также не создает независимый лог: если закрыть окно вывода и не настроить запись, результаты могут потеряться. Сохраняйте вывод важной задачи в файл или систему журналирования.

Для приложения, которое должно стартовать после reboot и перезапускаться при сбое, оформите systemd service. Screen/tmux хорошо подходят человеку, который подключился и наблюдает за процессом; service manager подходит для фоновой службы с известным unit, владельцем, логом и политикой рестарта.

Не запускайте долгий production-процесс в shell от root, если для него достаточно отдельной учетной записи. Мультиплексор сохраняет доступ этой учетной записи, а оставленная без блокировки общая сессия позволяет повторно подключиться. В multiuser-режиме GNU Screen настройте списки доступа, но не считайте блокировку терминала границей безопасности.

Журналируйте результат отдельно

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

Экранная прокрутка и история shell не подходят как единственный журнал обслуживания. Для экспорта базы, архива или обновления пишите вывод в файл с датой либо в системный journal. Если команда работает через pipeline, проверьте, что оболочка сохраняет ошибку первого этапа, а не только статус последней команды.

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

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

Если процесс должен работать после перезагрузки

Передайте автозапуск systemd, если команда - часть приложения, а не разовая операция человека. Unit-файл задает пользователя, рабочий каталог, исполняемую команду, переменные среды, зависимости и порядок рестарта. Секреты не храните прямо в опубликованном unit-файле с открытыми правами. После запуска проверяйте systemctl status имя-службы и journalctl -u имя-службы.

Запись вывода в файл или journal помогает понять, завершилось ли задание и что оно делало до сбоя. Для резервной копии или миграции проверяйте целостность полученного архива и код возврата команды, а не только то, что терминальная вкладка осталась открыта. Screen/tmux дают удобное управление интерактивной сессией, но не повторяют завершившуюся работу автоматически.

Когда сессия не найдена, проверьте имя пользователя, владельца и список detached sessions. Сессии каждого пользователя изолированы, поэтому tmux ls под root не обязательно покажет список другого аккаунта. Не запускайте сервисы постоянной работы в личной сессии, которую позже удалит администратор.

После возврата сохраните важный вывод отдельно и закройте только сессию, в которой завершена работа. Не удаляйте сессии по шаблону имени: сначала сопоставьте владельца, процесс и задачу.

Проверьте ручной сценарий: запустите безвредную команду с известным выводом, отсоединитесь, подключитесь во второй SSH-сессии и убедитесь, что экран сохранился. Затем изучите настройку SSH, просмотр процессов Linux и управление пользователями. Для системной службы смотрите резервное копирование и VPS/VDS. GNU Screen, tmux и руководство Ubuntu OpenSSH проверены 8 октября 2026 года; SSH-сессии читателя не открывались.