Cron vs systemd timer

Mi è stato recentemente segnalato che esiste un'alternativa a cron, vale a dire i timer di sistema.

Tuttavia, non so nulla sui timer systemd o systemd. Ho usato solo cron.

C'è una piccola discussione in Arch Wiki . Tuttavia, sto cercando un confronto dettagliato tra crone timer systemd, concentrandomi su pro e contro. Uso Debian, ma vorrei un confronto generale per tutti i sistemi per i quali sono disponibili queste due alternative. Questo set può includere solo distribuzioni Linux.

Ecco quello che so.

Cron è molto vecchio, risale alla fine degli anni '70. L'autore originale di cron è Ken Thompson, il creatore di Unix. Vixie cron, di cui i croni nelle moderne distribuzioni Linux sono discendenti diretti, risale al 1987.

Systemd è molto più recente e alquanto controverso. Wikipedia mi dice che la sua versione iniziale è stata il 30 marzo 2010.

Quindi, il mio attuale elenco di vantaggi di cron over systemd timer è:

1. Cron è garantito per essere in qualsiasi sistema simile a Unix, nel senso di essere un software supportato installabile. Questo non cambierà. Al contrario, systemd potrebbe o meno rimanere nelle distribuzioni Linux in futuro. È principalmente un sistema init e può essere sostituito da un diverso sistema init.

2. Cron è semplice da usare. Decisamente più semplice dei timer di sistema.

L'elenco corrispondente dei vantaggi dei timer systemd rispetto a cron è:

1. I timer di Systemd possono essere più flessibili e capaci. Ma vorrei esempi di questo.

Quindi, per riassumere, ecco alcune cose che sarebbe bello vedere in una risposta:

1. Un confronto dettagliato dei timer cron vs systemd, inclusi pro e contro dell'uso di ciascuno.
2. Esempi di cose che uno può fare e l'altro no.
3. Almeno un confronto side-by-side di uno script cron rispetto a uno script timer di systemd.

Ecco alcuni punti su quei due :

1. controllare cosa fa davvero il tuo cron job può essere un po 'un casino, ma tutti gli eventi del timer di sistema sono accuratamente registrati nel diario di sistema come le altre unità di sistema in base all'evento che rende le cose molto più facili.

2. i timer di sistema sono servizi di sistema con tutte le loro capacità per la gestione delle risorse, la programmazione della CPU IO, ...
   C'è un elenco:
   

   • filtri di chiamata di sistema
     
   • ID utente / gruppo
     
   • membershipcontrols
     
   • buon valore
     
   • Punteggio OOM
     
   • Classe e priorità di programmazione IO
     
   • Criterio di programmazione CPU CPU
     
   • umask affinità
     
   • pantaloni del timer
     
   • bit sicuri
     
   • accesso alla rete e, ...
     

3. con l'opzione delle dipendenze proprio come altri servizi di sistema, ci possono essere dipendenze dal tempo di attivazione.
   

4. Le unità possono essere attivate in diversi modi, anche la loro combinazione può essere configurata. i servizi possono essere avviati e attivati ​​da diversi eventi come utente, avvio, modifiche allo stato dell'hardware o, ad esempio, 5 minuti dopo aver collegato l'hardware e, ...

5. configurazione molto più semplice di alcuni file e tag diretti per eseguire diverse personalizzazioni in base alle proprie esigenze con i timer di sistema.

6. Abilita / disabilita facilmente il tutto con:

   systemctl enable/disable 
   

   e uccidi tutti i bambini del lavoro con:

   systemctl start/stop
   

7. i timer di systemd possono essere programmati con calendari e orari monotonici, che possono essere davvero utili in caso di fusi orari diversi e, ...

8. gli eventi di time systemd (calendario) sono più precisi di cron (sembra precisione 1s)

9. gli eventi orari di sistema sono più significativi, per quelli ricorrenti o anche quelli che dovrebbero verificarsi una volta, ecco un esempio dal documento :

   Sat,Thu,Mon-Wed,Sat-Sun → Mon-Thu,Sat,Sun *-*-*00:00:00
     Mon,Sun 12-*-* 2,1:23 → Mon,Sun 2012-*-* 01,02:23:00
                   Wed *-1 → Wed *-*-01 00:00:00
           Wed-Wed,Wed *-1 → Wed *-*-01 00:00:00
                Wed, 17:48 → Wed *-*-* 17:48:00 
   

10. Dal punto di vista dell'utilizzo della CPU il timer systemd riattiva la CPU al tempo trascorso, ma cron lo fa più spesso.

11. Gli eventi timer possono essere programmati in base ai tempi di fine delle esecuzioni, alcuni ritardi possono essere impostati tra le esecuzioni.

12. La comunicazione con altri programmi è anche notevole a volte è necessaria per alcuni altri programmi per conoscere i timer e lo stato dei loro compiti.

Direttamente dalla bocca del cavallo, per così dire: https://wiki.archlinux.org/index.php/Systemd/Timers#As_a_cron_replacement

Un estratto dalla pagina sopra:

Benefici

I principali vantaggi dell'utilizzo dei timer provengono da ogni lavoro con un proprio servizio di sistema. Alcuni di questi vantaggi sono:

• I lavori possono essere facilmente avviati indipendentemente dai loro timer. Questo semplifica il debug.
• Ogni lavoro può essere configurato per l'esecuzione in un ambiente specifico (consultare systemd.exec (5)).
• I lavori possono essere collegati a cgroups.
• I lavori possono essere impostati per dipendere da altre unità di sistema.
• I lavori vengono registrati nel journal di systemd per semplificare il debug.

Avvertenze

Alcune cose che sono facili da fare con cron sono difficili da fare solo con le unità timer.

• Complessità: per impostare un lavoro a tempo con systemd, creare due file ed eseguire un paio di comandi systemctl. Confrontalo con l'aggiunta di una singola riga a un crontab.
• E-mail: non esiste un equivalente incorporato al MAILTO di cron per l'invio di e-mail in caso di errore del lavoro. Vedere la sezione successiva per un esempio di impostazione di un equivalente utilizzando OnFailure =.