Не запускается задача launchd по расписанию на удалённом Mac? Руководство по диагностике 2026

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

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

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

Сначала отделите запуск через SSH от автоматического запуска

Успешная команда в интерактивной оболочке доказывает только то, что она выполнилась в условиях текущего SSH-сеанса. Она не подтверждает, что launchd использует того же пользователя, находит те же программы, видит те же переменные среды и имеет доступ к требуемым файлам. Apple описывает задания launchd как работу в определённом контексте запуска; назначение и окружение агента или системного демона нельзя выводить из того, что команда сработала вручную (обзор запланированных задач Apple, контексты системы и пользовательских сеансов).

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

Для первичной проверки выполните команду из SSH вручную и сохраните код завершения и вывод. Затем воспроизведите тот же запуск через конфигурацию задания, направив стандартный вывод и ошибки в файлы, доступные назначенному пользователю. В plist для launchd можно явно задать ProgramArguments, WorkingDirectory, StandardOutPath и StandardErrorPath; документация Apple по созданию заданий описывает конфигурацию агентов и демонов (создание Launch Daemons и Agents).

Таблица — не инструкция автоматически переносить задачу в системный контекст. Apple разделяет пользовательские агенты и системные демоны по назначению и окружению; выбор должен соответствовать требуемым ресурсам и поведению задания, а не стремлению добиться запуска любой ценой (назначение фоновых процессов и их контексты).

Почему задача работает в SSH, но не автоматически? Чаще всего условия различаются: в интерактивной оболочке доступны настройки профиля, пользовательский каталог, команда из PATH и открытая авторизация. Автоматический процесс не следует считать продолжением SSH-оболочки. Сравните значения и доступы в обоих сценариях, а не копируйте настройки терминала наугад.

Пользовательский запуск: LaunchAgent и сеанс

Выбирайте пользовательский агент, если задача обслуживает конкретного пользователя: читает его файлы, обращается к пользовательской конфигурации или предполагает доступность ресурсов его сеанса. Сначала сверьте владельца plist и скрипта, затем — права на рабочий каталог, входные файлы, место для журналов и целевой каталог результата. Доступность файла для администратора не гарантирует, что назначенная учётная запись сможет его прочитать или изменить.

Затем выясните, когда задача должна выполняться. Некоторые работы нужны после входа пользователя, другие — только при наличии активного сеанса, третьи должны продолжаться независимо от того, вошёл ли разработчик. Не подменяйте эти требования друг другом. Apple описывает LaunchAgent как средство запуска в пользовательском контексте, а LaunchDaemon — как системный вариант; подробности зависят от выбранного контекста и конфигурации (документация Apple по созданию заданий).

Проверьте конфигурацию на конкретных условиях эксплуатации:

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

Нужно ли удалённой задаче LaunchAgent или LaunchDaemon? Если работа требует файлов, настроек или ресурсов конкретного пользовательского сеанса, начните с LaunchAgent. Если она должна исполняться как системная фоновая работа без пользовательского сеанса и обходится системно доступными ресурсами, проверьте применимость LaunchDaemon. Не расширяйте права и не меняйте контекст, пока не установили, какое требование блокирует выполнение.

Фоновое обслуживание: границы LaunchDaemon

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

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

Для системного задания отдельно оцените каталоги и зависимости. Домашний каталог разработчика, пользовательские настройки оболочки и интерактивно созданные файлы нельзя считать частью системного окружения без проверки. То же касается доступа к сети или общему хранилищу: наличие подключения у SSH-клиента не доказывает, что автоматический процесс видит тот же ресурс. Документация Apple различает системные и пользовательские контексты, но конкретные права и доступы требуется проверять на целевом Mac и для выбранной конфигурации (контексты пользовательских сеансов и системы).

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

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

Графический интерфейс, авторизация и пользовательские секреты

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

Для каждого такого шага установите, где хранится необходимый секрет, кто имеет к нему доступ и в каком состоянии он доступен автоматической задаче. Apple описывает Keychain Services как программный интерфейс для работы с защищёнными секретами, но наличие секрета в связке ключей само по себе не доказывает доступность именно из выбранного контекста выполнения (документация Apple по Keychain Services). Сверьте способ получения секрета с документацией используемого инструмента и проверьте его на целевом Mac под назначенной учётной записью.

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

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

Команды и окружение: воспроизводимый минимальный запуск

Не предполагайте, что настройки из SSH будут доступны launchd. В оболочке команда может находиться благодаря PATH, профиль может устанавливать переменные, а относительный путь может работать только из каталога проекта. Для автоматического задания укажите абсолютный путь к интерпретатору или программе и передавайте аргументы отдельными элементами ProgramArguments. Apple отдельно описывает запуск и управление скриптами через Terminal и основы оболочечных сценариев (руководство Terminal по скриптам и launchd, основы Shell-скриптов).

Проверьте конфигурацию по отдельным категориям:

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

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

Если нужно проверить конфигурацию из SSH, используйте launchctl print для целевого пользовательского или системного контекста, а затем сопоставьте его вывод с метками и путями в plist. Вывод о состоянии задания полезен для диагностики, но сам по себе не удостоверяет, что полезная работа выполнилась. Для проверки запуска связывайте его с журналом процесса и изменением ожидаемого результата.

Проверка восстановления: фактический запуск и результат

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

Условия проверки зависят от назначения:

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

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

Используйте проверочный список и оставьте рядом ссылки на журналы и файлы результата. Это делает повторную диагностику предметной, а не зависящей от памяти дежурного:

• [ ] Контекст выбран по реальным зависимостям: пользовательский агент, системная служба или иной способ.
• [ ] Владелец задания совпадает с предполагаемой учётной записью процесса.
• [ ] Абсолютные пути, рабочий каталог и необходимые переменные проверены вне интерактивной оболочки.
• [ ] У процесса есть только требуемый доступ к входным, выходным файлам и внешним ресурсам.
• [ ] Графические операции, пользовательские секреты и интерактивные подтверждения отдельно проверены или вынесены из фонового сценария.
• [ ] Для запуска настроены читаемые журналы начала, ошибок и завершения без секретных данных.
• [ ] Проверено автоматическое срабатывание, а не только ручной вызов команды или загрузка конфигурации.
• [ ] После перезапуска подтверждены новый запуск и ожидаемый результат при нужном состоянии пользовательского сеанса.

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

Когда задача требует постоянно доступной macOS-среды, сначала сравните её реальные ограничения с текущим способом выполнения. Обычный SSH-сеанс может исчезнуть при отключении клиента; собственная машина требует обслуживания и может не соответствовать условиям размещения; общий Linux-сервер не заменяет macOS-инструменты и пользовательский контекст. При этом аренда удалённого Mac не решит автоматически задачу с графическим интерфейсом или секретами — эти зависимости всё равно нужно проверять. Для сравнения физических и виртуализированных вариантов изучите разбор bare metal и виртуализации macOS, а если нужен отдельный удалённый узел — доступные тарифы удалённой Mac-среды. Если после диагностики вам нужна именно длительно доступная macOS-среда для периодических задач, рассмотрите MacDate как вариант аренды и сначала подтвердите на целевом сценарии, что выбранный способ запуска удовлетворяет требованиям вашего процесса.