0 10 * * 3 o * 10 * * 3? Leggi il campo dei minuti

Entrambe le espressioni sembrano un mercoledì mattina, e solo una significa una volta. 0 10 * * 3 scatta alle 10:00 di mercoledì; * 10 * * 3 scatta ogni minuto dell'ora decima, sessanta occasioni per avviare lo stesso tunnel. Se il comando è un launcher che non verifica la presenza di una sessione, la seconda versione non è un errore di pianificazione, è un ciclo che produce proprietari in competizione. Leggi il campo dei minuti prima di qualsiasi altra cosa.

I cinque campi sono minuto, ora, giorno del mese, mese e giorno della settimana, in quest'ordine, e un asterisco nel primo significa ogni minuto.

Il campo dei minuti decide quante volte

Il numero iniziale è il minuto, quindi 0 10 * * 3 è il primo minuto dell'ora decima di mercoledì. Sostituirlo con un asterisco conserva l'ora e il giorno e toglie la proprietà di una sola volta, producendo sessanta corrispondenze. Cron non elimina i duplicati: ogni corrispondenza rilancia il comando. Non è una sottigliezza su cron, è semantica dei campi, e vale la pena leggere il riferimento dello scheduler installato perché l'ordine dei campi e la colonna facoltativa del nome utente differiscono tra crontab utente e di sistema.

Prova con un comando innocuo che registra il proprio timestamp per un giorno. Una riga nel log è una pianificazione; sessanta righe in un'ora sono una lezione.

Cosa fa un secondo avvio al primo

Un launcher ben educato nota che la connessione è già attiva e non fa nulla. Un'invocazione diretta di openvpn no: crea un altro processo, un altro tentativo di legare un dispositivo o una porta, e un altro insieme di rotte che competono per le stesse destinazioni. In NetworkManager, le richieste di attivazione ripetute per una connessione sono di solito idempotenti, ed è esattamente per questo che il problema resta nascosto finché qualcuno non usa un comando diverso. La pianificazione dovrebbe chiedere al proprietario che già gestisce il tunnel.

Poi decidi cosa significa una richiesta mentre la connessione si sta stabilendo. Né l'attivazione doppia né una coda di avvii in attesa sono ovviamente corrette; scegline una e fai implementare al launcher, invece di lasciare che lo scheduler decida per caso.

Conta i campi prima del comando

I crontab utente e di sistema differiscono nel fatto che una colonna del nome utente compaia prima del comando. Una voce copiata tra i due o gira con l'account sbagliato o passa il nome utente come prima parola del comando. Controlla il riferimento installato invece di una guida, e conta i campi nella tua riga. Una voce a cinque campi con una sesta parola prima del comando è un crontab di sistema; la stessa riga in un crontab utente tenta di eseguire quella parola come programma.

L'identità di esecuzione porta con sé l'ambiente. Un job cron non eredita un portachiavi sbloccato, una richiesta interattiva di password o la directory di lavoro in cui hai testato.

Attendi la disponibilità, non l'orologio

Un avvio riuscito non è un tunnel funzionante. Il client potrebbe ancora risolvere il proprio endpoint, autenticarsi o installare rotte quando il job termina. Qualsiasi attività dipendente dovrebbe attendere la risorsa protetta di cui ha davvero bisogno, con un timeout limitato e un errore registrato, invece di un numero fisso di secondi. Questa distinzione separa una pianificazione che funziona quasi sempre da una che fallisce in silenzio nella mattina caotica.

Se a quell'ora è richiesta una MFA interattiva, il job può richiamare l'attenzione di una persona ma non può fornire la risposta. Mantieni esplicito quel caso invece di incorporare una password riutilizzabile o riprovare all'infinito.

Per un'attivazione davvero una tantum, usa il meccanismo one-shot supportato. Una regola ricorrente che va ricordata e rimossa è un futuro doppio avvio.