Планирана задача, изпълнена без 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 на хоста не замества ограничена политика за задачата.

Решете дали ново събитие може да се застъпи с все още изпълнявана задача, пазете това правило при собственика на натоварването и направете повторението безопасно за операцията с данни. Спирането на задача при прекъсване ограничава работата, без да гарантира нищо за резервния трафик.

Приемете работния поток по три случая: готов път, недостъпен път и загуба по време на изпълнение. Всичко по-малко тества графика, а не задачата.