GitHub Actions: что делать, если self-hosted Mac Runner офлайн после перезагрузки? Руководство по устранению неполадок 2026

GitHub помечает self-hosted Runner как офлайн, если хост недоступен, приложение Runner не работает или не может связаться с GitHub. Поэтому один статус в интерфейсе не доказывает, что сломалась регистрация Runner. Начинайте с проверки самого Mac, а не с удаления записи. Именно такие разные причины объединяет официальное руководство GitHub по статусу Offline и диагностике self-hosted Runner.

Сверьте три независимых источника наблюдений:

• Страница Runner в GitHub показывает, что узел офлайн, и указывает его имя и метки.
• Результат удалённого подключения показывает, доступен ли сам Mac через используемый командой канал.
• Запись в журнале дежурств, системе мониторинга питания или консоли управления показывает, запускалась ли машина после перезагрузки.

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

Для разбора полезно явно разделить состояния: «хост доступен», «служба запущена», «Runner связан с GitHub», «задача назначена» и «workflow успешно завершён». Каждое требует своего подтверждения. Смешивание этих проверок приводит к типичной ошибке: команда видит доступный Mac и предполагает, что CI уже восстановлен, хотя приложение Runner не запущено или нужная задача не подходит этому узлу.

Если Mac доступен, проверьте, был ли Runner установлен как служба и запустилась ли она после системной загрузки. Перейдите в каталог установки Runner и проверьте состояние штатным скриптом svc.sh status, если служба на этом узле настроена через него. Команды управления службой и её конфигурацией описаны в документации GitHub по настройке приложения Runner.

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

В macOS важно различать контексты LaunchAgent и LaunchDaemon. Первый относится к пользовательскому сеансу, второй запускается в системном контексте. Если команда рассчитывает на запуск без входа пользователя, но Runner стартует только после входа в учётную запись, причина может быть в выбранном контексте, а не в неисправности GitHub. Разницу между этими механизмами описывает документация Apple по управлению системными службами.

Сопоставьте конфигурацию службы с фактическим запуском:

• Найдите установленную службу и убедитесь, что она относится к текущему каталогу Runner.
• Проверьте её состояние штатным скриптом и изучите сообщения системы при запуске.
• Установите, зависит ли запуск от пользовательского входа.
• Сравните состояние локальной службы с записью узла в GitHub.
• Если системная служба не стартовала, выясните причину в журналах до попытки повторной установки.

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

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

Проверяйте цепочку по частям. Убедитесь, что DNS разрешает необходимые имена, затем проверьте маршрут через корпоративный прокси, если он используется. После этого разберите ошибки TLS, доверие к сертификатам и доступ процесса к необходимым адресам GitHub. Условия работы self-hosted Runner через прокси изложены в официальной документации GitHub о настройке прокси.

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

Затем сопоставьте результат сетевых проверок с диагностикой Runner. GitHub рекомендует использовать журналы приложения для расследования проблем; параметры диагностического журналирования описаны в инструкции по включению debug logging для workflow. Ищите сообщения, которые относятся к моменту потери связи: ошибки разрешения имён, отказ прокси, сбой TLS или повторные попытки соединения. Зафиксируйте, что именно проверялось, чтобы следующий дежурный не повторял весь разбор без новых данных.

Таблица задаёт порядок поиска, а не диагноз. Например, запись «процесс работает» не исключает проблем с DNS, а запись «Runner онлайн» не доказывает, что он подходит для конкретного workflow. После каждого исправления повторяйте проверку соответствующего слоя: иначе несколько одновременных изменений усложнят поиск первопричины.

Когда узел снова отображается онлайн, проверьте, действительно ли он может принять нужную задачу. В workflow поле runs-on задаёт требования к среде; фактический Runner должен удовлетворять им по меткам и доступу. Группа Runner также ограничивает, где может выполняться работа. Правила выбора среды описаны в документации GitHub о назначении Runner для job.

Сверьте конфигурацию в репозитории с записью Runner в GitHub. Проверьте:

• Все ли метки, указанные в runs-on, присутствуют у нужного узла.
• Не изменились ли имя, набор меток или группа при восстановлении.
• Разрешён ли репозиторию доступ к группе Runner.
• Не направлено ли задание в другую группу или на Runner с дополнительными требованиями.

Порядок управления метками приведён в руководстве GitHub по назначению меток Runner, а правила доступа к группам — в описании разрешений для Runner groups. Если Runner не соответствует условиям выбора, GitHub не обязан назначать ему задачу только потому, что он онлайн.

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

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

Решение по условиям допуска

• Если Mac недоступен, узел не запускается по утверждённому сценарию или остаётся ошибка DNS, прокси либо TLS — не возвращайте его в очередь; сначала устраните неисправность соответствующего слоя.
• Если служба запущена и Runner связан с GitHub, но workflow ждёт в очереди — исправьте метки, группу или разрешения; не переустанавливайте Runner без подтверждения проблемы регистрации.
• Если контрольное задание назначено нужному узлу, завершает необходимые шаги и возвращает проверяемый результат — допускайте его к производству по внутренним правилам выпуска.
• Если проверено только состояние «онлайн», но не сборка и не требуемые инструменты — оставьте узел в ограниченном режиме до полноценной приёмки.

Почему Mac Runner после перезагрузки отображается как офлайн?

Статус офлайн объединяет несколько причин: хост может быть выключен или недоступен, приложение Runner может не работать, а запущенный процесс — не иметь связи с GitHub. Поэтому начните с доступности самого Mac и только затем проверяйте службу и сеть. Повторная регистрация не устраняет недоступность хоста и может добавить отдельную проблему.

Как проверить запуск службы Runner в macOS?

Проверьте службу из каталога установленного Runner штатным svc.sh status, если установка использует этот механизм. Затем выясните, создан ли для неё объект launchd и запускается ли он в пользовательском или системном контексте. Если служба зависит от входа пользователя, отсутствие сеанса после перезагрузки может объяснить незапущенный Runner. Сопоставьте локальное состояние с записью в GitHub.

Что делать, если процесс Runner работает, а GitHub всё равно показывает офлайн?

Проверьте DNS, прокси и TLS именно для среды процесса Runner, а затем изучите диагностические журналы приложения. Не считайте обычный доступ к веб-сайту подтверждением доступа Runner: сетевые настройки могут различаться. Не отключайте проверку TLS. Исправляйте конкретную причину отказа и после этого повторно проверяйте связь и статус узла в GitHub.

Как проверить, что восстановленный Runner принимает задания?

Сопоставьте runs-on с метками узла, проверьте группу Runner и разрешения репозитория. Затем запустите безопасный workflow, который проверяет назначение задания, получение кода, нужные инструменты и возврат результата. До завершения этой проверки статус онлайн не является достаточным основанием для возврата узла к производственной сборке.

Собственный Mac даёт команде прямой контроль над оборудованием и удобен, если узел постоянно загружен, требует физического подключения устройств или должен работать в особой локальной инфраструктуре. Но после перезапуска именно ваша команда отвечает за восстановление удалённого доступа, запуск службы, сеть и замену неисправного оборудования. При расширении CI потребность в дополнительных узлах также означает новые закупки и обслуживание.

Для временных нагрузок, пилота или дополнительного удалённого узла стоит сравнить эту модель с арендой Mac. Она позволяет оценить доступ к удалённому компьютеру и условия поставки до принятия решения о закупке, но не отменяет необходимости проектировать Runner, управление секретами и приёмку CI. Проверьте подтверждённые условия и варианты доступа на странице MESHLAUNCH для удалённого Mac, а требования к конкретной конфигурации сверяйте с информацией о Mac mini.

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