cron-creazione-di-un-timer | Linuxiano.it
Privacy Policy

cron-creazione-di-un-timer

Cron generazione di prossima generazione Con systemd: creazione di un timer

Hai bisogno di programmare qualche attività sul tuo computer? Una cosa semplice con Ubuntu o Linux

Cron, software completamente dedicato a lanciare il compito giusto al momento giusto. Ma questo strumento è stato progettato pensando alla semplicità e alla fine potresti avere brutte sorprese. Se sei mai riuscito a pianificare un’attività su Windows, hai utilizzato Windows Task Planner. Di default ha una GUI, ma non è così semplice da usare: questi due sistemi avviano un processo a una data e ora fissa.

Ecco un esempio per capire in che modo systemd può diventare utile.
Quali sono le insidie ​​che i timer di sistema eviteranno?

Se possiedi una macchina con dati che ti interessano, ti consigliamo di avere una copia dei tuoi dati in un altro posto, probabilmente più sicuro. Se gestisci un server, è bene sapere, come recuperare dati se il tuo hard disk fallisce e ti impedisce di recuperarli?

Quindi, hai impostato il backup ogni settimana o ogni giorno. Puoi configurarlo usando cron, lo pianifichi alle 4:24 del mattino, ma qui inizia il problema: cosa succede se il tuo server è spento dalle 4:15AM alle 4:35 AM per qualsiasi motivo?

Beh, è ​​probabile che cron salterà quel backup. Questo potrebbe essere fondamentale se ciò accade spesso e in silenzio o se il tuo codice si basa sul fatto che viene eseguito e potrebbe non funzionare diversamente. Generalmente ciò accade quando si imposta un’attività di pulizia tramite cron e non si avvia. Improvvisamente il tuo codice potrebbe non avere abbastanza spazio per continuare e si romperà.

Tuttavia, se mancate un lancio può essere un problema? Il tuo compito è troppo lento. Se impostato per essere eseguito ogni 10 minuti, ma occorrono 15 minuti per completarlo, cron o Windows lanceranno felicemente un’altra attività anche se l’attività corrente non è ancora finita e così, avrai 2 istanze del tuo compito in esecuzione contemporaneamente, che è la ricetta perfetta per il disastro. Quando un programma viene eseguito contemporaneamente mentre non è progettato, probabilmente corromperà file, altri software, database e il server diventerà improvvisamente una nave che affonda come il Titanic.

OK, forse sto andando troppo lontano con il Titanic ma era solo per farti capito l’idea. Mentre systemd non avrebbe potuto fare molto per salvare questa nave, può aiutarti con tutte queste carenze e assicurarti una vacanza natalizia più lunga grazie ai bug che ti eviteranno. È ora di sapere come impostare i timer di sistema.

Come pianificare il backup automatico del server?

Prima di tutto, i timer systemd attivano lo stesso servizio, quindi prima di pianificare il tuo compito, dovrai prima renderlo un servizio. Fortunatamente, ho scritto una guida per creare il servizio systemd, in questo modo ti presenterò il modo di lavorare con systemd. Dovresti leggerlo prima di andare avanti. A meno che tu non sappia esattamente cosa stai facendo, il tuo file di servizio systemd non dovrebbe contenere alcuna impostazione WantedBy. Se desiderate avviare il servizio in un momento specifico, probabilmente non desiderate avviarlo all’avvio.

Grazie al sistema di servizio systemd, possiamo avere più istanze dell’attività in esecuzione: se un’attività è già in esecuzione, salterà tale avvio e lascerà l’attività in esecuzione al termine del lavoro.

Una volta che hai un servizio systemd da programmare, crea un file con lo stesso nome del tuo servizio, che termina con .timer invece di .service. Nel nostro esempio di backup automatico, il servizio sarebbe automatizzato-backup.service e il timer sarebbe automatizzato-backup.timer. Entrambi i file dovrebbero essere nella stessa directory. Come ti ho detto nell’articolo del servizio systemd, ti consiglio di scrivere questi file in un posto normale come la tua home directory e poi, copiarli in una cartella systemd, una volta che hai finito le tue modifiche.

Quindi, lascia che ti mostri come si presenta il nostro file timer:
[Unità] Descrizione=Pianifica i backup durante le ore di punta

[Timer] OnCalendar=*-*-*03:00:00

Terminale

RandomizedDelaySec=6200

Molto simile ai servizi systemd, ci sono 3 sezioni. [Unità] o [Installa] funzionano esattamente come spiegato nel mio articolo sui servizi di sistema. Da notare che WantedBy è importante perché i timer possono essere avviati o fermati, quindi se non diciamo a systemd di avviare il timer durante l’avvio, non si innescherà mai. timers.Target è un target systemd speciale per i timer.

Ora, la sezione [Timer]. Al suo interno, troverai tutte le impostazioni relative a quando il timer dovrebbe attivarsi. Per il nostro backup automatico, ho detto a systemd di eseguirlo tra le 3:00 e le 5:00 al fuso orario del server. L’ora esatta è casuale ogni giorno.

OnCalendar = imposta il timer relativo all’ora del server (wallclock), ad esempio ogni domenica alle 13:00. Se hai già usato cron in precedenza, dovresti avere molta familiarità con questa sintassi. Tuttavia ha alcuni benefici aggiunti.

Ad esempio, se vuoi che qualcosa succeda ogni ora, puoi fare così:
OnCalendar= hourly

e ogni giorno:

Terminale

OnCalendar=daily

Infatti, supporta tutti i seguenti valori:

  • minutamente
  • ogni ora
  • quotidiano
  • mensile
  • settimanalmente
  • annuale
  • trimestrale
  • semestrale

C’è tuttavia un problema con queste parole chiave: ad esempio, trigger giornalieri sempre a mezzanotte, che spesso un’ora di picco nei sistemi informatici. Ecco perché consiglio di utilizzare RandomizedDelaySec (il suo utilizzo è specificato di seguito). Comunque per il backup non è una buona opzione: la mezzanotte non è fuori dalle ore di punta, è piuttosto il contrario. Quindi abbiamo bisogno di impostare in modo più preciso quando vogliamo vedere quell’attività lanciata.

Se vuoi un maggiore controllo, puoi scrivere una data come 2018-12-07 12:50:37. Bene, se sei così specifico, innescherai il timer una sola volta. Per renderlo ricorrente, sostituirai qualsiasi di questi elementi con * asterisco.

Terminale

OnCalendar=*-*-* 03:00:00

Come puoi vedere sopra, nel esempio del backup, tutta la parte della data è * – * – *, il che significa che dovrebbe verificarsi ogni giorno di ogni mese di ogni anno. Ora se lo fai:

Terminale

OnCalendar=*-12-25 03:00:00

Quindi viene eseguito ogni 25 dicembre alle 3 del mattino. Perfetto timer di sistema per Babbo Natale – anche se dubito che ne abbia mai bisogno! Quindi l’asterisco aggiunge ricorrenza dove lo metti. Se lo metti in campo anno, significa “ogni anno”, ecc.

Infine, puoi aggiungere UTC alla fine della riga per utilizzare l’ora UTC anziché il fuso orario locale. Ad esempio, alcuni servizi ripristinano le proprie quote API a mezzanotte, ma per evitare qualsiasi distorsione del fuso orario utilizza UTC. Quindi per tali compiti, dovresti fare:

Terminale

OnCalendar=UTC daily

Ora, risolviamo un altro problema: le ore di punta. systemd ha anche un setting per combattere contro questo.

RandomizedDelaySec = consente di ritardare l’attività di una quantità casuale di tempo. Il valore è il numero massimo di secondi che il timer ritarderà inteso specificamente per questi casi. Ti ricordi che in systemd, ogni giorno si innesca sempre a mezzanotte? Bene, settimanalmente si attiva sempre a mezzanotte di lunedì e trigger annuali a mezzanotte del 1 ° gennaio, uno dei peggiori picchi dell’anno con interruzioni di rete ovunque. Certamente non vuoi che ciò accada.

Aggiungendo un ritardo, rimuovi il problema: verrà automaticamente ritardato in un momento sconosciuto il tuo compito. La casualità qui è importante perché è molto più probabile che sia anche quando è casuale e un carico uniforme consente di ottimizzare al meglio i tuoi compiti.

Supponiamo che tu debba eseguire i tuoi compiti intorno alle 7 del mattino, ma vuoi consentire un piccolo ritardo di massimo 15 minuti, come farebbe:

Terminale

RandomizedDelaySec=800

Questo dovrebbe essere sufficiente per i ritardi. A volte anche i ritardi di millisecondi sono sufficienti per evitare picchi involontari.

Persistente = si occupa dei trigger del timer persi. Cosa succede se il tuo server è spento durante la notte? Bene, il backup non si innescherebbe mai. Impostarlo su true consente a systemd di eseguirlo all’avvio successivo in questi casi. In questo modo saprai, in un modo o nell’altro, che il compito del timer verrà eseguito. Il suo utilizzo è semplice, basta fare questo:

Terminale

Persistent=true

Questo ha comunque uno svantaggio che è davvero difficile da evitare in ogni caso: quando mancano più task da diversi timer, tutti funzioneranno all’avvio e rallenteranno l’avvio. Secondo me è molto meglio che se non funziona mai e dopo tutto è normale, il momento più appropriato per eseguire il timer è quando è programmato, in seguito sarà probabilmente comunque inappropriato.

OnBootSec = è l’ultima opzione che ti mostrerò (ma non meno importante). È se si desidera attivare un timer un po ‘di tempo dopo l’avvio anziché in base al calendario. Ad esempio, se è necessario verificare all’avvio se il server viene avviato correttamente e funziona come previsto, è possibile scrivere un servizio di controllo e utilizzare tale impostazione del timer per attivarlo dopo che il sistema ha avuto il tempo sufficiente per l’avvio.

Supponiamo che il sistema abbia bisogno di 3 minuti per avviarsi, puoi fare:

Terminale

OnBootSec=180

E nonostante il suo nome, puoi anche fare:

Terminale

OnBootSec=3 minutes

Se si precisa sia OnBootSec che OnCalendar, avvierà il servizio ogni volta che si verifichi uno di questi 2 eventi.

Ok, ora è il momento di salvare il tuo file, copiarlo nella cartella di sistema se hai seguito il mio consiglio precedente e verificare se il tuo timer funziona correttamente.

Abilita il tuo nuovo timer e monitoraggio

Per testare il tuo nuovo timer, devi dire a systemd che hai aggiunto un nuovo timer, quindi devi digitare questo comando:

Terminale

sudo systemctl daemon-reload

Ora, systemd prenderà in considerazione il tuo nuovo timer e guarderà da vicino quando eseguire il tuo compito. Poiché systemd è sempre in esecuzione, dopo tutto è uno dei migliori candidati per gestire ed eseguire le attività pianificate.

Una cosa che potresti trovare controintuitiva però: un timer è disabilitato di default. Per abilitarlo, è necessario eseguire questo comando:

Terminale

sudo systemctl enable –now automated-backup.timer

Probabilmente vorrai vedere se il tuo timer funziona come previsto. Buone notizie: systemd è anche abbastanza gentile da avere un comando che ti dice quando è stato lanciato l’ultima volta e quando è programmato il prossimo avvio (tranne se il timer è impostato per essere eseguito solo all’avvio, come systemd non sa quando il sistema si riavvierà , ovviamente). Ecco questo comando:

Terminale

systemctl status automated-backup.timer

Infine, quando non hai più bisogno del timer, puoi disabilitarlo anche:

Terminale

sudo systemctl disable –now automated-backup.timer

Conclusione

Usando i timer di sistema, la gestione delle attività pianificate è di un livello successivo: onestamente, personalmente ritengo che le attività programmate avrebbero dovuto essere così da anni.

Oh, una piccola sorpresa per te: tutti i timer di sistema sono registrati in un sistema ben strutturato con filtraggio, rotazione del registro e simili. Quindi ti invito a vedere come puoi vedere i registri sulle tue attività pianificate!

Grazie! per l’utilizzo della Guida di Linuxiano.

Trovi questo tutorial utile? Condividi con i tuoi amici per tenerlo in vita.
Sii il primo a commentare, apprezzo i tuoi suggerimenti. Per ulteriori domande potete commentare qui sotto.