0 10 * * 3 vagy * 10 * * 3? Olvassuk a percmezőt

Mindkét kifejezés szerda reggelnek tűnik, és csak az egyik jelent egyszeri futást. 0 10 * * 3 szerdán 10:00-kor fut le; * 10 * * 3 a tizedik óra minden percében lefut, hatvan esély ugyanazon alagút elindítására. Ha a parancs olyan indító, amely nem ellenőrzi a meglévő munkamenetet, a második változat nem ütemezési hiba, hanem olyan hurok, amely versengő tulajdonosokat hoz létre. Bármi más elolvasása előtt olvassuk el a percmezőt.

Az öt mező a perc, az óra, a hónap napja, a hónap és a hét napja, ebben a sorrendben, és az elsőben lévő csillag minden percet jelent.

A percmező dönti el, hányszor

A vezető szám a perc, tehát a 0 10 * * 3 a tizedik óra első perce szerdán. Csillagra cserélve megmarad az óra és a nap, és elvész az egyszeri tulajdonság, ami hatvan egyezést eredményez. A cron nem távolítja el az ismétlődéseket: minden egyezés újraindítja a parancsot. Ez nem a cron finomsága, hanem mezőszemantika, és érdemes elolvasni a telepített ütemező referenciáját, mert a mezők sorrendje és az opcionális felhasználónév-oszlop eltér a felhasználói és a rendszer crontab között.

Teszteljük egy ártalmatlan paranccsal, amely egy napon át rögzíti a saját időbélyegét. Egy sor a naplóban ütemezés; hatvan sor egy órán belül tanulság.

Mit tesz a második indítás az elsővel

Egy jól nevelt indító észreveszi, hogy a kapcsolat már él, és nem tesz semmit. Egy nyers openvpn hívás nem: újabb folyamatot hoz létre, újabb kísérletet egy eszköz vagy egy port lekötésére, és újabb útvonalkészletet, amely ugyanazokért a célokért verseng. A NetworkManagerben egy kapcsolat ismételt aktiválási kérései általában idempotensek, és éppen ezért marad rejtve a probléma, amíg valaki más parancsot nem használ. Az ütemezésnek azt a tulajdonost kellene kérdeznie, aki már kezeli az alagutat.

Ezután döntsük el, mit jelent egy kérés, miközben a kapcsolat éppen kiépül. Sem a kettős aktiválás, sem a várakozó indítások sora nem nyilvánvalóan helyes; válasszunk egyet, és az indító valósítsa meg, ahelyett hogy az ütemező véletlenül döntene.

Számoljuk meg a mezőket a parancs előtt

A felhasználói és a rendszer crontab abban különbözik, hogy a parancs előtt megjelenik-e felhasználónév-oszlop. A kettő között átmásolt bejegyzés vagy rossz fiókkal fut, vagy a felhasználónevet adja át a parancs első szavaként. A telepített referenciát nézzük meg, ne egy útmutatót, és számoljuk meg a mezőket a saját sorunkban. Az ötmezős bejegyzés hatodik szóval a parancs előtt rendszer crontab; ugyanez a sor felhasználói crontabban megpróbálja azt a szót programként futtatni.

A végrehajtási identitás magával hordozza a környezetet. Egy cron-feladat nem örököl feloldott kulcskarikát, interaktív jelszókérést vagy azt a munkakönyvtárat, amelyben teszteltünk.

A készültséget várjuk, nem az órát

A sikeres indítás nem működő alagút. Lehet, hogy az ügyfél a feladat kilépésekor még a végpontját oldja fel, hitelesít vagy útvonalakat telepít. Minden függő feladatnak a ténylegesen szükséges védett erőforrásra kellene várnia, korlátozott időtúllépéssel és naplózott hibával, nem pedig rögzített számú másodpercre. Ez a különbség választja el a többnyire működő ütemezést attól, amelyik a forgalmas reggelen csendben elbukik.

Ha abban az órában interaktív MFA szükséges, a feladat kérheti egy ember figyelmét, de nem tudja megadni a választ. Tartsuk ezt az esetet explicitnek, ahelyett hogy újrahasználható jelszót ágyaznánk be vagy a végtelenségig próbálkoznánk.

Valóban egyszeri aktiváláshoz a támogatott egyszeri mechanizmust használjuk. Az ismétlődő szabály, amelyet meg kell jegyezni és el kell távolítani, jövőbeli kettős indítás.