En planlagt opgave, der kørte uden VPN, ser fin ud

Opgavens status siger succes, loggen viser en fuldført kørsel, og dataene er forældede eller mangler. Den kombination betyder normalt, at den planlagte opgave startede uden den sti, den havde brug for, og at noget længere nede slugte fejlen. En tidsplan, der udløses til tiden, siger intet om, hvorvidt netværket var klar. Kløften mellem de to fakta er, hvor denne fejl lever.

Adgang hører til kørslen, ikke til eksistensen af en cron-fil.

En grøn kørsel er ikke en fuldført opgave

En planlægger noterer, at en proces startede og senere afsluttedes; den aner ikke, om processen nåede den ressource, den findes for. Et script, der behandler en mislykket forbindelse som et tomt resultat, eller fanger en fejl og afslutter med nul, vil se sundt ud for evigt. Symptonet er ikke en rød status; det er en plausibel status knyttet til manglende arbejde.

Navngiv, hvad kørslen faktisk har brug for, før I beslutter, hvordan den skal kontrolleres. En sikkerhedskopi kan have brug for privat DNS og et godkendt endepunkt, ikke blot en tunnelproces.

Kontrollér forbindelsen, ikke grænsefladenavnet

En grænseflade ved navn tun0 kan findes uden den session, der betyder noget, og en anden forbindelse kan eje det navn. Kontrollér det konkrete objekt, opgaven afhænger af: én profilidentitet, én tjenesteinstans eller en lille godkendt handling mod ressourcen. Hold kontrollen tidsbegrænset, og hold legitimationsoplysninger ude af procesargumenter og diagnostiske logfiler.

Definér også resultatet ved afbrydelse. Et almindeligt spring, et nyt forsøg inden for et kort vindue og en operatørsynlig overskredet frist er tre forskellige svar, og en tilbagevendende tidsplan vælger ikke mellem dem.

Spring og fejl er forskellige resultater

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

I en systemd-udrulning kører ExecCondition= den kontroller, før arbejdsbyrden starter. Dens udgangsadfærd er specifik: nul fortsætter, koder fra et til 254 springer de resterende startkommandoer over uden at markere enheden som fejlet, og 255 eller unormal afslutning fejler den. Det giver tre forskellige signaler, nyttige kun hvis kontrollerens kontrakt bevidst knyttes til dem. Indstillinger, der omdefinerer succes, kan ændre billedet, så dokumentér tilknytningen.

Det er registreringen af spring, der gør designet ærligt. En sprunget kørsel, der ikke vises nogen steder, kan ikke skelnes fra en kørsel, der lykkedes, og behandling af enhver kontrollerfejl som et stille spring skjuler en brudt udrulning på ubestemt tid.

Beskyt hele kørslen, ikke kun starten

En parathedskontrol observerer verden før start; den overvåger ikke hver socket bagefter. Når en direkte sti aldrig er acceptabel for denne opgave, vedhæft en godkendt udgående politik, der håndhæves løbende og dækker DNS, IPv6 og tunnelens egen transport. At skifte værtens globale IPv6-tilstand er ikke en erstatning for en afgrænset politik på opgaven.

Beslut, om en ny hændelse må overlappe en opgave, der stadig kører, hold den regel hos arbejdsbyrdens ejer, og gør nyt forsøg sikkert for databehandlingen. At stoppe en opgave ved afbrydelse begrænser arbejdet uden at garantere noget om fallback-trafik.

Accepter arbejdsgangen på tre tilfælde: klar sti, utilgængelig sti og tab under kørslen. Alt mindre tester tidsplanen, ikke opgaven.