Команды Linux и навыки работы с оболочкой
tmux против экрана: сравнение менеджеров сеансов
tmux и screen решают одну и ту же древнюю проблему: ваша работа не должна умереть вместе с вашей сетью. Сеансы живут на сервере, сохраняются при отключении и могут быть разделены на панели; screen — это стабильный предшественник, поставляемый повсюду, tmux — преемник с более разумными настройками по умолчанию, панелями с возможностью сценариев и развивающейся экосистемой. Функционально они перекрываются десять к одному, и честный выбор — это инструмент, который уже есть на ваших серверах, плюс привычки конфигурации, которые ваша команда фактически сохранит.
Главное
- Гигиена сеанса является основной ценностью: tmux new -s Deploy / Screen -S Deploy для запуска, tmux ls / screen -ls для просмотра фермы и присоединения по точному имени, поэтому повторное подключение ночного задания коллеги — это поиск, а не догадка.
- Отсоединяйтесь изящно (префикс-d), выходите намеренно: закрытие всего сеанса с выходом внутри панелей — это то, как теряются незавершенные длинные задания; «Отстраняться, если вы действительно не имели этого в виду» — это привычка, а не предпочтение.
- Разделения ведут себя лучше в tmux: % и " разделяют панели, плюс изменение размера стрелки под префиксом и дополнительный режим мыши; отсчет экрана | и S к одним и тем же концам с более сложным изменением размера.
- Обратная прокрутка играет решающую роль: режим копирования tmux ищет историю ([ then /), навигация по экрану ^a [ работоспособна, но груба, а в журналах размером в несколько ГБ поиск по хвостам превосходит прокрутку.
- Возможности сценариев склоняются к tmux: клавиши отправки и панель захвата позволяют автоматизации управлять и читать сеансы, поэтому CI и инструментарий предпочитают его; screen тоже может пойти туда, но со старыми идиомами.
- Общие сеансы работают в обоих случаях: два подключения к одному сеансу отражают все в реальном времени, то есть парную отладку или проверку рискованных команд в режиме реального времени; продолжайте печатать дисциплинированно, иначе зеркало покажет и ваши опечатки.
- Культура конфигурации отличается: tmux создал разделенную экосистему конфигурации (темы, плагины, разумные настройки по умолчанию для каждой команды), экран работает на одном ~/.screenrc; на практике tmux масштабируется по всей команде, и экран остается личным.
- Перезагрузка завершает все: сеансы живут в памяти сервера, поэтому для длительных заданий нужны настоящие задания (журналы, контрольные точки, перезапускаемые сценарии) плюс менеджер сеансов сверху; tmux — это страховка, а не долговечность.
Заметка из практики
Потерянный сеанс представлял собой шестичасовую миграцию данных, прерванную сбоем VPN, и ничто на диске не знало, на каком этапе мы находимся. Все, что дольше, чем перерыв на кофе, теперь получает имя в tmux и возобновляется на следующее утро с помощью tmux ls вместо пожимания плечами.
Частые вопросы
Если я выучу только один, какой?
tmux, если ваш парк уже не использует screen повсюду; его настройки по умолчанию, скриптовые перехватчики и импульс сообщества — это то, чем было последнее десятилетие, и привычки передаются достаточно хорошо, чтобы покрыть чрезвычайную ситуацию на экране.
Безопасно ли проводить один сеанс двум людям?
Да, и это стандартный прием парной отладки; оба видят одинаковые нажатия клавиш, поэтому договоритесь о том, кому принадлежит клавиатура, и относитесь к любой деструктивной команде как к запросу на изменение с присоединенной второй парой глаз.
Почему цвета во время сеанса выглядят неправильно?
Несоответствие TERM: внутренний терминал должен объявить tmux-256color или screen-256color, удаленный хост должен иметь запись (infocmp сообщает вам), и разборчивость в первую очередь, гордость темы во вторую.
Сохраняются ли сеансы после перезагрузки сервера?
Нет: сеансы живут в памяти, и перезагрузка очищает их, пока сохраняются диски; перезапускаемые сценарии и журналы на диске — это уровень надежности, tmux — уровень прерываний, а путать их — это классический сбой.
Как мы берём на себя команды linux и навыки работы с оболочкой
Честно: чаще всего к нам приходят после того, как команда попробовала справиться сама. Команды и сценарии сценариев, которые решают, управляет ли администратор сервером или борется с ним: поиск, преобразование, передача и контроль текста и процессов с помощью инструментов, которые есть в каждой базовой установке. Услуга Безопасность серверов Linux и Администрирование серверов существует как раз затем, чтобы не изучать команды linux и навыки работы с оболочкой на своих ошибках: настройку, ночные сюрпризы и постоянное наблюдение мы берём на себя.