Плановая задача, выполненная без VPN, выглядит нормально

Статус задачи сообщает об успехе, журнал показывает завершённый запуск, а данные устарели или отсутствуют. Такое сочетание обычно означает, что плановая задача стартовала без нужного пути, и что-то ниже по потоку проглотило сбой. Расписание, срабатывающее вовремя, ничего не говорит о том, была ли готова сеть. Именно в зазоре между этими двумя фактами и живёт этот сбой.

Допуск принадлежит запуску, а не существованию файла cron.

Зелёный запуск — это не завершённая задача

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

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

Проверяйте соединение, а не имя интерфейса

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

Определите и результат при отключении. Обычный пропуск, повторная попытка в коротком окне и видимый оператору пропущенный срок — это три разных ответа, и повторяющееся расписание между ними не выбирает.

Пропуски и сбои — это разные результаты

[Service]
Type=oneshot
User=worker
ExecCondition=/usr/local/libexec/check-office-path
ExecStart=/usr/local/bin/private-task

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

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

Защищайте весь запуск, а не только начало

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

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

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