Een geplande taak die zonder de VPN liep, ziet er goed uit
De status zegt succes en de gegevens ontbreken. Koppel elke uitvoering aan de exacte verbinding en registreer overslagen apart in plaats van op het schema te vertrouwen.
De taakstatus zegt succes, het logboek toont een voltooide uitvoering, en de gegevens zijn verouderd of ontbreken. Die combinatie betekent meestal dat de geplande taak begon zonder het pad dat hij nodig had, en dat iets stroomafwaarts de fout heeft ingeslikt. Een schema dat op tijd afgaat zegt niets over of het netwerk klaar was. De kloof tussen die twee feiten is waar deze fout leeft.
Toelating hoort bij de uitvoering, niet bij het bestaan van een cron-bestand.
Een groene uitvoering is geen voltooide taak
Een planner noteert dat een proces startte en later eindigde; hij heeft geen idee of dat proces de bron bereikte waarvoor het bestaat. Een script dat een mislukte verbinding als een leeg resultaat behandelt, of een fout opvangt en met nul afsluit, ziet er voor altijd gezond uit. Het symptoom is geen rode status; het is een plausibele status die aan ontbrekend werk hangt.
Benoem wat de uitvoering echt nodig heeft voordat je besluit hoe je die controleert. Een back-up heeft misschien privé-DNS en een geauthenticeerd eindpunt nodig, niet alleen een tunnelproces.
Controleer de verbinding, niet de interfacenaam
Een interface met de naam tun0 kan bestaan zonder de sessie die ertoe doet, en een andere verbinding kan die naam bezitten. Controleer het specifieke object waarvan de taak afhangt: één profielidentiteit, één service-instantie of een kleine goedgekeurde bewerking tegen de bron. Houd de controle tijdsgebonden en houd inloggegevens buiten procesargumenten en diagnostische logboeken.
Definieer ook de uitkomst bij ontkoppeling. Een gewone overslag, een nieuwe poging binnen een kort venster en een voor de operator zichtbare gemiste deadline zijn drie verschillende antwoorden, en een terugkerend schema kiest niet tussen hen.
Overslagen en fouten zijn verschillende uitkomsten
[Service] Type=oneshot User=worker ExecCondition=/usr/local/libexec/check-office-path ExecStart=/usr/local/bin/private-task
In een systemd-implementatie voert ExecCondition= die controle uit vóór de werkbelasting. Het exitgedrag is specifiek: nul gaat door, codes van één tot 254 slaan de resterende startopdrachten over zonder de unit als mislukt te markeren, en 255 of een abnormale beëindiging laat hem mislukken. Dat geeft drie verschillende signalen, alleen nuttig als het contract van de controle er bewust op is afgestemd. Instellingen die succes herdefiniëren kunnen het beeld veranderen, dus documenteer de toewijzing.
Het registreren van overslagen is wat het ontwerp eerlijk maakt. Een overgeslagen uitvoering die nergens verschijnt, is niet te onderscheiden van een uitvoering die slaagde, en elke controlefout als een stille overslag behandelen verbergt een kapotte implementatie voorgoed.
Bescherm de hele uitvoering, niet alleen de start
Een gereedheidscontrole observeert de wereld vóór de start; daarna bewaakt hij niet elke socket. Wanneer een direct pad voor deze taak nooit aanvaardbaar is, voeg een goedgekeurd uitgaand beleid toe dat continu wordt afgedwongen en DNS, IPv6 en het eigen transport van de tunnel dekt. Het omzetten van de globale IPv6-status van de host is geen vervanging voor een beleid dat op de taak is toegespitst.
Bepaal of een nieuwe gebeurtenis een nog lopende taak mag overlappen, houd die regel bij de eigenaar van de werkbelasting, en maak een nieuwe poging veilig voor de gegevensbewerking. Een taak stoppen bij verbreking beperkt het werk zonder iets te garanderen over terugvalverkeer.
Accepteer de werkstroom in drie gevallen: gereed pad, niet-beschikbaar pad en verlies tijdens de uitvoering. Alles minder test het schema, niet de taak.