Una tasca programada que es va executar sense la VPN sembla correcta

L'estat de la tasca diu èxit, el registre mostra una execució completada i les dades són obsoletes o absents. Aquesta combinació normalment vol dir que la tasca programada es va iniciar sense el camí que necessitava, i que alguna cosa més avall es va empassar la fallada. Una programació que s'activa a temps no diu res sobre si la xarxa estava a punt. La bretxa entre aquests dos fets és on viu aquesta fallada.

L'admissió pertany a l'execució, no a l'existència d'un fitxer cron.

Una execució verda no és una tasca completada

El planificador anota que un procés es va iniciar i després va sortir; no té ni idea si aquell procés va arribar al recurs per al qual existeix. Un script que tracta una connexió fallida com un resultat buit, o que captura un error i surt amb zero, semblarà sa per sempre. El símptoma no és un estat vermell; és un estat plausible adjunt a feina absent.

Anomeneu què necessita realment l'execució abans de decidir com comprovar-ho. Una còpia de seguretat pot necessitar DNS privat i un punt final autenticat, no només un procés de túnel.

Comproveu la connexió, no el nom de la interfície

Una interfície anomenada tun0 pot existir sense la sessió que importa, i una altra connexió pot posseir aquest nom. Comproveu l'objecte concret del qual depèn la tasca: una identitat de perfil, una instància de servei o una petita operació aprovada contra el recurs. Mantingueu la comprovació limitada en el temps i manteniu les credencials fora dels arguments del procés i dels registres de diagnòstic.

Definiu també el resultat desconnectat. Un salt ordinari, un reintent dins d'una finestra curta i un termini incomplert visible per a l'operador són tres respostes diferents, i una programació recurrent no tria entre elles.

Els salts i les fallades són resultats diferents

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

En un desplegament systemd, ExecCondition= executa aquest comprovador abans de la càrrega de treball. El seu comportament de sortida és específic: zero continua, els codis d'un a 254 salten les ordres d'inici restants sense marcar la unitat com a fallida, i 255 o una terminació anormal la fan fallar. Això dona tres senyals diferents, útils només si el contracte del comprovador s'hi assigna deliberadament. Els paràmetres que redefineixen l'èxit poden canviar la imatge, així que documenteu l'assignació.

Registrar els salts és el que fa honest el disseny. Una execució saltada que no apareix enlloc és indistingible d'una execució que va tenir èxit, i tractar cada error del comprovador com un salt silenciós amaga un desplegament trencat indefinidament.

Protegiu tota l'execució, no només l'inici

Una comprovació de preparació observa el món abans del llançament; no vigila cada sòcol després. Quan un camí directe no és mai acceptable per a aquesta tasca, adjunteu una política de sortida aprovada que s'apliqui contínuament i cobreixi DNS, IPv6 i el transport propi del túnel. Canviar l'estat global d'IPv6 de l'amfitrió no substitueix una política limitada a la tasca.

Decidiu si un esdeveniment nou pot solapar-se amb una tasca encara en curs, manteniu aquesta regla amb el propietari de la càrrega de treball i feu segur el reintent per a l'operació de dades. Aturar una tasca en desconnectar limita la feina sense garantir res sobre el trànsit de reserva.

Accepteu el flux de treball en tres casos: camí a punt, camí no disponible i pèrdua durant l'execució. Qualsevol cosa menys prova la programació, no la tasca.