tmux на удалённом Mac: остановятся ли задачи при обрыве? Руководство по настройке 2026

Согласно официальному руководству tmux, клиент подключается к уже работающему серверу tmux, а сервер хранит сессии независимо от окна SSH-клиента. Поэтому разрыв SSH обычно не останавливает задачу внутри tmux: после повторного входа вы можете снова подключиться к сессии. Но tmux не защищает от сна macOS, перезагрузки узла, сбоя самого процесса или удаления хоста. На этой неделе сначала проведите контролируемую проверку отключения, затем отдельную проверку сна и перезапуска; для обязательного автозапуска используйте службу macOS или CI-планировщик, а не одну только интерактивную сессию.

Эта статья предназначена для удалённых разработчиков, которым нужно продолжить компиляцию, тестирование, загрузку или обработку данных после обрыва SSH. Она также полезна DevOps-инженерам, отличающим сохранение терминала от настоящего фонового сервиса, и платформенным администраторам, принимающим удалённый Mac после проверки отказоустойчивости.

Граница ответственности tmux

Главная ошибка при диагностике — считать пустой терминал доказательством остановки процесса. В цепочке участвуют несколько независимых объектов:

• SSH-соединение между вашим компьютером и Mac;
• интерактивный Shell;
• клиент tmux, присоединённый к терминалу;
• сервер tmux, управляющий сессиями и окнами;
• дочерний процесс сборки, теста или скрипта.

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

Эта модель согласуется с руководством tmux по клиентам, серверам и сессиям. Не удаляйте socket, не завершайте сервер tmux и не запускайте задачу повторно, пока не сохранены вывод, PID и рабочий каталог. Иначе вы можете превратить временную проблему отображения в настоящий дубль сборки или конфликт записи.

Признаки живой и завершившейся задачи

После повторного входа сначала соберите состояние, а не нажимайте клавиши запуска:

whoami
pwd
tmux list-sessions
tmux list-windows
ps -axo pid,ppid,stat,etime,command | grep -E 'xcodebuild|swift|python|node'

Имена процессов здесь приведены как примеры; замените их на команду вашего проекта. Наличие сессии доказывает только наличие сервера tmux, но не выполнение задачи. Для уверенного вывода нужны одновременно рабочий PID, ожидаемый каталог и свежие изменения в журнале.

Создание сессии и повторное подключение

Правильный минимальный цикл начинается с именованной сессии. Подключитесь к Mac по SSH, перейдите в каталог проекта и создайте отдельный контейнер:

cd /путь/к/проекту
tmux new-session -s сборка

Теперь запускайте задачу уже внутри tmux:

./scripts/build.sh 2>&1 | tee build.log

Имя и путь являются заполнителями: подставьте каталог и команду вашего проекта. Чтобы отсоединиться, не завершая процесс, используйте сочетание клавиш tmux для detach либо команду:

tmux detach-client

После нового входа список сессий покажет сохранённое имя:

tmux list-sessions
tmux attach-session -t сборка

В официальном Getting Started этот принцип описан как разделение клиентского подключения и серверной сессии. Не создавайте новую сессию с похожим названием до проверки старой: сборка, build и сессия другого пользователя — это разные объекты.

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

• [ ] создана именованная сессия tmux;
• [ ] whoami показывает ожидаемую учётную запись;
• [ ] pwd указывает на правильный каталог;
• [ ] запущен именно нужный процесс;
• [ ] PID записан до отключения;
• [ ] лог направляется в файл, а не только в окно терминала;
• [ ] SSH отключён контролируемо;
• [ ] после входа сессия найдена по точному имени;
• [ ] PID, каталог и новые строки журнала совпадают с состоянием до отключения.

Если после повторного входа сессия не найдена, проверьте учётную запись и переменную окружения TMUX. На одном Mac разные пользователи могут видеть разные серверы tmux. Удаление socket или принудительное завершение процесса сервера — крайняя мера: это уничтожит доступ к живым сессиям и не восстановит уже потерянную задачу.

Среда Shell и секреты после переподключения

Сохранённая сессия и новое окружение — не одно и то же. При новом входе может измениться login Shell, PATH, домашний каталог, путь к Homebrew, переменные проекта или доступ к SSH Agent. Поэтому задача может быть жива, но новая команда диагностики не находить git, swift, node или другой инструмент.

Сначала сравните значения:

echo "$SHELL"
echo "$HOME"
echo "$PATH"
command -v brew
command -v git
env | sort > /tmp/env-after-login.txt

Не вставляйте реальные ключи и токены в статью, журнал или командную строку. Для проверки используйте только имена переменных и безопасный тест доступа. FAQ tmux отдельно объясняет, что окружение, передаваемое серверу, не следует считать автоматически синхронизированным при каждом новом подключении. Это особенно важно, если вы изменили профиль Shell после создания сессии.

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

Для начальной установки tmux можно использовать официальную страницу Formula Homebrew. Сам факт установки через Homebrew не делает задачу системной службой и не решает вопрос сна или перезапуска.

Сон macOS и потеря доступности

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

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

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

Перезапуск и постоянные задачи

После перезапуска Mac сначала подтвердите, что система действительно загрузилась и доступна по SSH. Возможность входа ещё не означает, что проект, переменные, ключи и фоновые процессы восстановлены. Документация Apple по Remote Login описывает включение удалённого входа, но не превращает произвольную команду в устойчивый планировщик.

Для задачи, которая должна запускаться при загрузке, изучите launchd. В руководстве Apple по созданию launchd-задач описаны plist-конфигурация, условия запуска и управление жизненным циклом. Для приложений доступны также механизмы Service Management. Выбирайте область запуска, пользователя, права на каталог и политику повторной попытки явно.

До перехода на фоновую службу запишите:

• какую команду нужно запускать;
• от какого пользователя она выполняется;
• какие переменные нужны;
• где находятся журналы;
• что считается успешным завершением;
• сколько повторных попыток допустимо;
• как остановить задачу без повреждения данных.

Для одноразовой компиляции лучше сохранить команду, журнал и артефакты, а затем выполнить безопасный повтор после проверки незавершённого состояния. Для регулярного процесса с расписанием, уведомлениями и восстановлением используйте launchd или CI Runner. В этом случае tmux остаётся инструментом ручной диагностики, а не единственным уровнем надёжности.

Проверка журналов и восстановление

Для просмотра журнала после повторного подключения не полагайтесь только на экран tmux:

cd /путь/к/проекту
tail -n 100 build.log
grep -E 'error|failed|success|completed' build.log
ps -axo pid,etime,stat,command

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

Практичная схема восстановления выглядит так:

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

Так вы отвечаете не на вопрос «есть ли окно tmux», а на более важный вопрос: «можно ли доказать, что задача выполняется или завершилась корректно».

Тестовая матрица для удалённого Mac

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

Итоговая классификация проста. Интерактивная сборка, ручная отладка и разовая обработка подходят для tmux. Фоновая задача, которая должна пережить выход пользователя, но не обязана сама планироваться, требует отдельного журнала и контроля питания. Производственный процесс с автозапуском, повторами и уведомлениями следует передать macOS-службе или CI-планировщику.

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

Оценка вариантов эксплуатации

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

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

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

Начните с одной небольшой задачи: выполните отключение SSH, найдите сессию, сохраните лог, затем проведите контролируемый перезапуск. Если результаты подтверждают нужный уровень восстановления, закрепите процедуру в документации; если нет — перенесите задачу в launchd или CI и только после этого масштабируйте работу на удалённый Mac.