Планова задача, виконана без 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 хоста не замінює політику, обмежену задачею.

Вирішіть, чи може нова подія перекривати ще виконувану задачу, тримайте це правило у власника робочого навантаження й зробіть повторну спробу безпечною для операції з даними. Зупинка задачі при відключенні обмежує роботу, але нічого не гарантує щодо резервного трафіку.

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