Sto convertendo i miei lavori cron in timer di sistema. Ho usato i timer per alcuni anni, ma di solito ho imparato quanto basta per svolgere il compito su cui stavo lavorando. Durante la ricerca per questa serie di systemd, ho appreso che i timer di systemd hanno alcune capacità molto interessanti.
Come i lavori cron, i timer di systemd possono attivare eventi, script e programmi della shell, a intervalli di tempo specifici, ad esempio una volta al giorno, in un giorno specifico del mese (forse solo se è un lunedì) o ogni 15 minuti durante l'orario lavorativo dalle 8:00 alle 18:00. I timer possono anche fare alcune cose che i lavori cron non possono. Ad esempio, un timer può attivare uno script o un programma per l'esecuzione di un determinato periodo di tempo dopo un evento come l'avvio, l'avvio, il completamento di un'attività precedente o anche il precedente completamento dell'unità di servizio chiamata dal timer.
Timer di manutenzione del sistema
Quando Fedora o qualsiasi distribuzione basata su systemd viene installata su un nuovo sistema, crea diversi timer che fanno parte delle procedure di manutenzione del sistema che si verificano in background di qualsiasi host Linux. Questi timer attivano gli eventi necessari per le attività di manutenzione comuni, come l'aggiornamento dei database di sistema, la pulizia delle directory temporanee, la rotazione dei file di registro e altro ancora.
Ad esempio, esaminerò alcuni dei timer sulla mia workstation principale utilizzando systemctl status *timer comando per elencare tutti i timer sul mio host. Il simbolo dell'asterisco funziona come per il globbing dei file, quindi questo comando elenca tutte le unità timer di sistema:
[root@testvm1 ~]# systemctl status *timer
● mlocate-updatedb.timer - Updates mlocate database every day
Loaded: loaded (/usr/lib/systemd/system/mlocate-updatedb.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left
Triggers: ● mlocate-updatedb.service
Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Updates mlocate database every day.
● logrotate.timer - Daily rotation of log files
Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left
Triggers: ● logrotate.service
Docs: man:logrotate(8)
man:logrotate.conf(5)
Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Daily rotation of log files.
● sysstat-summary.timer - Generate summary of yesterday's process accounting
Loaded: loaded (/usr/lib/systemd/system/sysstat-summary.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
Trigger: Fri 2020-06-05 00:07:00 EDT; 15h left
Triggers: ● sysstat-summary.service
Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Generate summary of yesterday's process accounting.
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
Trigger: Mon 2020-06-08 00:00:00 EDT; 3 days left
Triggers: ● fstrim.service
Docs: man:fstrim
Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Discard unused blocks once a week.
● sysstat-collect.timer - Run system activity accounting tool every 10 minutes
Loaded: loaded (/usr/lib/systemd/system/sysstat-collect.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
Trigger: Thu 2020-06-04 08:50:00 EDT; 41s left
Triggers: ● sysstat-collect.service
Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Run system activity accounting tool every 10 minutes.
● dnf-makecache.timer - dnf makecache --timer
Loaded: loaded (/usr/lib/systemd/system/dnf-makecache.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
Trigger: Thu 2020-06-04 08:51:00 EDT; 1min 41s left
Triggers: ● dnf-makecache.service
Jun 02 08:02:33 testvm1.both.org systemd[1]: Started dnf makecache –timer.
● systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static; vendor preset: disabled)
Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
Trigger: Fri 2020-06-05 08:19:00 EDT; 23h left
Triggers: ● systemd-tmpfiles-clean.service
Docs: man:tmpfiles.d(5)
man:systemd-tmpfiles(8)
Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Daily Cleanup of Temporary Directories.
Ogni timer ha almeno sei righe di informazioni ad esso associate:
- La prima riga contiene il nome del file del timer e una breve descrizione del suo scopo.
- La seconda riga mostra lo stato del timer, se è caricato, il percorso completo del file dell'unità timer e la preimpostazione del fornitore.
- La terza riga indica il suo stato attivo, che include la data e l'ora in cui il timer è diventato attivo.
- La quarta riga contiene la data e l'ora in cui il timer verrà attivato successivamente e un tempo approssimativo prima che si verifichi l'attivazione.
- La quinta riga mostra il nome dell'evento o del servizio attivato dal timer.
- Alcuni (ma non tutti) i file di unità systemd hanno puntatori alla documentazione pertinente. Tre dei timer nell'output della mia macchina virtuale hanno puntatori alla documentazione. Questo è un bel (ma opzionale) bit di dati.
- L'ultima riga è la registrazione a giornale per l'istanza più recente del servizio attivata dal timer.
A seconda del tuo host, probabilmente avrai un diverso set di timer.
Crea un timer
Sebbene possiamo decostruire uno o più timer esistenti per imparare come funzionano, creiamo la nostra unità di servizio e un'unità timer per attivarla. Useremo un esempio abbastanza banale per mantenere questo semplice. Al termine, sarà più facile capire come funzionano gli altri timer e determinare cosa stanno facendo.
Per prima cosa, crea un semplice servizio che esegua qualcosa di base, come free comando. Ad esempio, potresti voler monitorare la memoria libera a intervalli regolari. Crea il seguente myMonitor.service file unit nel /etc/systemd/system directory. Non è necessario che sia eseguibile:
# This service unit is for testing timer units
# By David Both
# Licensed under GPL V2
#
[Unit]
Description=Logs system statistics to the systemd journal
Wants=myMonitor.timer
[Service]
Type=oneshot
ExecStart=/usr/bin/free
[Install]
WantedBy=multi-user.target
Ora esaminiamo lo stato e testiamo la nostra unità di servizio per assicurarci che funzioni come previsto.
[root@testvm1 system]# systemctl status myMonitor.service
● myMonitor.service - Logs system statistics to the systemd journal
Loaded: loaded (/etc/systemd/system/myMonitor.service; disabled; vendor preset: disabled)
Active: inactive (dead)
[root@testvm1 system]# systemctl start myMonitor.service
[root@testvm1 system]#
Dov'è l'uscita? Per impostazione predefinita, l'output standard (STDOUT ) dai programmi eseguiti dalle unità di servizio systemd viene inviato al giornale systemd, che lascia un record che puoi visualizzare ora o in seguito, fino a un certo punto. (Analizzerò le strategie di inserimento nel diario e conservazione di sistema in un prossimo articolo di questa serie.) Guarda il diario in modo specifico per la tua unità di servizio e solo per oggi. Il -S opzione, che è la versione breve di --since , ti consente di specificare il periodo di tempo in cui il journalctl lo strumento dovrebbe cercare le voci. Questo non perché non ti interessino i risultati precedenti, in questo caso non ce ne saranno, è per ridurre il tempo di ricerca se il tuo host è in esecuzione da molto tempo e ha accumulato un gran numero di voci nel diario:
[root@testvm1 system]# journalctl -S today -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT, end at Thu 2020-06-11 09:40:47 EDT. --
Jun 11 09:12:09 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 11 09:12:09 testvm1.both.org free[377966]: total used free shared buff/cache available
Jun 11 09:12:09 testvm1.both.org free[377966]: Mem: 12635740 522868 11032860 8016 1080012 11821508
Jun 11 09:12:09 testvm1.both.org free[377966]: Swap: 8388604 0 8388604
Jun 11 09:12:09 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
[root@testvm1 system]#
Un'attività attivata da un servizio può essere un singolo programma, una serie di programmi o uno script scritto in qualsiasi linguaggio di scripting. Aggiungi un'altra attività al servizio aggiungendo la riga seguente alla fine del [Service] sezione del myMonitor.service file dell'unità:
ExecStart=/usr/bin/lsblkRiavvia il servizio e controlla il diario per i risultati, che dovrebbero assomigliare a questo. Dovresti vedere i risultati di entrambi i comandi nel diario:
Jun 11 15:42:18 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 11 15:42:18 testvm1.both.org free[379961]: total used free shared buff/cache available
Jun 11 15:42:18 testvm1.both.org free[379961]: Mem: 12635740 531788 11019540 8024 1084412 11812272
Jun 11 15:42:18 testvm1.both.org free[379961]: Swap: 8388604 0 8388604
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: sda 8:0 0 120G 0 disk
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─sda1 8:1 0 4G 0 part /boot
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: └─sda2 8:2 0 116G 0 part
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─VG01-root 253:0 0 5G 0 lvm /
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─VG01-swap 253:1 0 8G 0 lvm [SWAP]
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─VG01-usr 253:2 0 30G 0 lvm /usr
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─VG01-tmp 253:3 0 10G 0 lvm /tmp
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─VG01-var 253:4 0 20G 0 lvm /var
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: └─VG01-home 253:5 0 10G 0 lvm /home
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: sr0 11:0 1 1024M 0 rom
Jun 11 15:42:18 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 11 15:42:18 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Ora che sai che il tuo servizio funziona come previsto, crea il file dell'unità timer, myMonitor.timer in /etc/systemd/system e aggiungi quanto segue:
# This timer unit is for testing
# By David Both
# Licensed under GPL V2
#
[Unit]
Description=Logs some system statistics to the systemd journal
Requires=myMonitor.service
[Timer]
Unit=myMonitor.service
OnCalendar=*-*-* *:*:00
[Install]
WantedBy=timers.target
Il OnCalendar specificazione dell'ora nel myMonitor.timer file , *-*-* *:*:00 , dovrebbe attivare il timer per eseguire myMonitor.service unità ogni minuto. Esplorerò OnCalendar impostazioni un po' più avanti in questo articolo.
Per ora, osserva tutte le voci del diario relative all'esecuzione del servizio quando viene attivato dal timer. Potresti anche seguire il timer, ma seguire il servizio ti consente di vedere i risultati quasi in tempo reale. Esegui journalctl con il -f (segui) opzione:
[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --
Avvia ma non abilitare il timer e guarda cosa succede dopo che è stato eseguito per un po':
[root@testvm1 ~]# systemctl start myMonitor.service
[root@testvm1 ~]#
Un risultato si presenta subito e i successivi arrivano a intervalli di un minuto. Guarda il diario per qualche minuto e vedi se noti le stesse cose che ho fatto io:
[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --
Jun 13 08:39:18 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:39:18 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:39:19 testvm1.both.org free[630566]: total used free shared buff/cache available
Jun 13 08:39:19 testvm1.both.org free[630566]: Mem: 12635740 556604 10965516 8036 1113620 11785628
Jun 13 08:39:19 testvm1.both.org free[630566]: Swap: 8388604 0 8388604
Jun 13 08:39:18 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: sda 8:0 0 120G 0 disk
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─sda1 8:1 0 4G 0 part /boot
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: └─sda2 8:2 0 116G 0 part
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─VG01-root 253:0 0 5G 0 lvm /
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─VG01-swap 253:1 0 8G 0 lvm [SWAP]
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─VG01-usr 253:2 0 30G 0 lvm /usr
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─VG01-tmp 253:3 0 10G 0 lvm /tmp
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─VG01-var 253:4 0 20G 0 lvm /var
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: └─VG01-home 253:5 0 10G 0 lvm /home
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: sr0 11:0 1 1024M 0 rom
Jun 13 08:40:46 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:40:46 testvm1.both.org free[630572]: total used free shared buff/cache available
Jun 13 08:40:46 testvm1.both.org free[630572]: Mem: 12635740 555228 10966836 8036 1113676 11786996
Jun 13 08:40:46 testvm1.both.org free[630572]: Swap: 8388604 0 8388604
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: sda 8:0 0 120G 0 disk
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─sda1 8:1 0 4G 0 part /boot
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: └─sda2 8:2 0 116G 0 part
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─VG01-root 253:0 0 5G 0 lvm /
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─VG01-swap 253:1 0 8G 0 lvm [SWAP]
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─VG01-usr 253:2 0 30G 0 lvm /usr
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─VG01-tmp 253:3 0 10G 0 lvm /tmp
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─VG01-var 253:4 0 20G 0 lvm /var
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: └─VG01-home 253:5 0 10G 0 lvm /home
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: sr0 11:0 1 1024M 0 rom
Jun 13 08:40:46 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:40:46 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Jun 13 08:41:46 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:41:46 testvm1.both.org free[630580]: total used free shared buff/cache available
Jun 13 08:41:46 testvm1.both.org free[630580]: Mem: 12635740 553488 10968564 8036 1113688 11788744
Jun 13 08:41:46 testvm1.both.org free[630580]: Swap: 8388604 0 8388604
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: sda 8:0 0 120G 0 disk
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─sda1 8:1 0 4G 0 part /boot
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: └─sda2 8:2 0 116G 0 part
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─VG01-root 253:0 0 5G 0 lvm /
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─VG01-swap 253:1 0 8G 0 lvm [SWAP]
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─VG01-usr 253:2 0 30G 0 lvm /usr
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─VG01-tmp 253:3 0 10G 0 lvm /tmp
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─VG01-var 253:4 0 20G 0 lvm /var
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: └─VG01-home 253:5 0 10G 0 lvm /home
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: sr0 11:0 1 1024M 0 rom
Jun 13 08:41:47 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:41:47 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Assicurati di controllare lo stato sia del timer che del servizio.
Altro sugli amministratori di sistema
- Abilita blog Sysadmin
- The Automated Enterprise:una guida alla gestione dell'IT con l'automazione
- eBook:Ansible Automation per SysAdmins
- Racconti dal campo:una guida per l'amministratore di sistema all'automazione IT
- eBook:una guida a Kubernetes per SRE e amministratori di sistema
- Ultimi articoli sull'amministratore di sistema
Probabilmente hai notato almeno due cose nel diario. Innanzitutto, non è necessario fare nulla di speciale per causare il STDOUT da ExecStart attiva nel myMonitor.service unità da memorizzare nel diario. Tutto ciò fa parte dell'utilizzo di systemd per l'esecuzione dei servizi. Tuttavia, significa che potrebbe essere necessario prestare attenzione all'esecuzione di script da un'unità di servizio e alla quantità di STDOUT generano.
La seconda cosa è che il timer non si attiva esattamente al minuto a :00 secondi o addirittura a un minuto esatto dall'istanza precedente. Questo è intenzionale, ma può essere ignorato se necessario (o se offende solo la sensibilità dell'amministratore di sistema).
Il motivo di questo comportamento è impedire l'attivazione simultanea di più servizi. Ad esempio, puoi utilizzare specifiche temporali come Settimanale, Giornaliera e altro. Queste scorciatoie sono tutte definite per attivarsi alle 00:00:00 del giorno in cui vengono attivate. Quando più timer vengono specificati in questo modo, esiste una forte probabilità che tentino di avviarsi contemporaneamente.
i timer di sistema sono progettati intenzionalmente per attivarsi in modo piuttosto casuale intorno al tempo specificato per cercare di prevenire trigger simultanei. Si attivano in modo semi-casuale all'interno di una finestra temporale che inizia all'ora di attivazione specificata e termina all'ora specificata più un minuto. Questo tempo di attivazione viene mantenuto in una posizione stabile rispetto a tutte le altre unità timer definite, secondo il systemd.timer pagina man. Puoi vedere nelle voci del diario sopra che il timer si è attivato immediatamente all'avvio e poi circa 46 o 47 secondi dopo ogni minuto.
Il più delle volte, tali tempi di trigger probabilistici vanno bene. Quando si pianificano attività come i backup da eseguire, purché vengano eseguite durante le ore di riposo, non ci saranno problemi. Un amministratore di sistema può selezionare un'ora di inizio deterministica, ad esempio 01:05:00 in una tipica specifica di lavoro cron, per non entrare in conflitto con altre attività, ma esiste un'ampia gamma di valori temporali che lo faranno. Un minuto di casualità in un'ora di inizio di solito è irrilevante.
Tuttavia, per alcune attività, i tempi di attivazione esatti sono un requisito assoluto. Per quelli, puoi specificare una maggiore precisione dell'intervallo di tempo di attivazione (entro un microsecondo) aggiungendo un'istruzione come questa al Timer sezione del file dell'unità timer:
AccuracySec=1usGli intervalli di tempo possono essere utilizzati per specificare l'accuratezza desiderata e per definire gli intervalli di tempo per eventi ripetuti o occasionali. Riconosce le seguenti unità:
- usec, noi, µs
- msec, ms
- secondi, secondi, secondi, s
- minuti, minuti, minuti, m
- ore, ora, ora, h
- giorni, giorno, d
- settimane, settimana, w
- mesi, mese, M (definito come 30,44 giorni)
- anni, anno, y (definito come 365,25 giorni)
Tutti i timer predefiniti in /usr/lib/systemd/system specificare un intervallo molto più ampio per la precisione perché i tempi esatti non sono critici. Guarda alcune delle specifiche nei timer creati dal sistema:
[root@testvm1 system]# grep Accur /usr/lib/systemd/system/*timer
/usr/lib/systemd/system/fstrim.timer:AccuracySec=1h
/usr/lib/systemd/system/logrotate.timer:AccuracySec=1h
/usr/lib/systemd/system/logwatch.timer:AccuracySec=12h
/usr/lib/systemd/system/mlocate-updatedb.timer:AccuracySec=24h
/usr/lib/systemd/system/raid-check.timer:AccuracySec=24h
/usr/lib/systemd/system/unbound-anchor.timer:AccuracySec=24h
[root@testvm1 system]#
Visualizza il contenuto completo di alcuni dei file dell'unità timer in /usr/lib/systemd/system directory per vedere come sono costruiti.
Non è necessario abilitare il timer in questo esperimento per attivarlo all'avvio, ma il comando per farlo sarebbe:
# systemctl enable myMonitor.timerI file unit che hai creato non devono essere eseguibili. Inoltre, non hai abilitato l'unità di servizio perché è attivata dal timer. È comunque possibile attivare manualmente l'unità di servizio dalla riga di comando, se lo si desidera. Provalo e osserva il diario.
Vedi le pagine man per systemd.timer e systemd.time per ulteriori informazioni sulla precisione del timer, le specifiche dell'ora dell'evento e gli eventi di attivazione.
Tipi di timer
i timer di sistema hanno altre capacità che non si trovano in cron, che si attiva solo su date e orari specifici, ripetitivi e in tempo reale. i timer di sistema possono essere configurati per attivarsi in base ai cambiamenti di stato in altre unità di sistema. Ad esempio, un timer potrebbe essere configurato per attivare un tempo trascorso specifico dopo l'avvio del sistema, dopo l'avvio o dopo l'attivazione di un'unità di servizio definita. Questi sono chiamati timer monotoni. Monotonico si riferisce a un conteggio o sequenza che aumenta continuamente. Questi timer non sono persistenti perché si ripristinano dopo ogni avvio.
La tabella 1 elenca i timer monotoni insieme a una breve definizione di ciascuno, nonché a OnCalendar timer, che non è monotono e viene utilizzato per specificare tempi futuri che possono essere o meno ripetitivi. Queste informazioni derivano da systemd.timer pagina man con alcune modifiche minori.
| Timer | Monotonico | Definizione |
|---|---|---|
OnActiveSec= | X | Definisce un timer relativo al momento in cui il timer viene attivato. |
OnBootSec= | X | Definisce un timer relativo all'avvio della macchina. |
OnStartupSec= | X | Definisce un timer relativo al primo avvio del gestore servizi. Per le unità timer di sistema, questo è molto simile a OnBootSec= , poiché il gestore del servizio di sistema generalmente si avvia molto presto all'avvio. È utile principalmente quando configurato in unità in esecuzione nel gestore del servizio per utente, poiché il gestore del servizio utente generalmente si avvia solo al primo accesso, non durante l'avvio. |
OnUnitActiveSec= | X | Definisce un timer relativo all'ultima attivazione del timer da attivare. |
OnUnitInactiveSec= | X | Definisce un timer relativo a quando il timer da attivare è stato disattivato l'ultima volta. |
OnCalendar= | Questo definisce i timer in tempo reale (cioè l'orologio da parete) con le espressioni degli eventi del calendario. Vedi systemd.time(7) per ulteriori informazioni sulla sintassi delle espressioni di eventi del calendario. In caso contrario, la semantica è simile a OnActiveSec= e relative impostazioni. Questo timer è quello più simile a quelli usati con il servizio cron. |
Tabella 1:definizioni dei timer di sistema
I timer monotoni possono utilizzare gli stessi nomi di scorciatoia per i loro intervalli di tempo di AccuracySec istruzione menzionata prima, ma systemd normalizza quei nomi in secondi. Ad esempio, potresti voler specificare un timer che attivi un evento una volta, cinque giorni dopo l'avvio del sistema; potrebbe essere simile a:OnBootSec=5d . Se l'host è stato avviato a 2020-06-15 09:45:27 , il timer si attiverebbe alle 2020-06-20 09:45:27 o entro un minuto dopo.
Specifiche degli eventi del calendario
Le specifiche degli eventi del calendario sono una parte fondamentale dell'attivazione dei timer negli orari ripetitivi desiderati. Inizia osservando alcune specifiche utilizzate con OnCalendar impostazione.
systemd e i suoi timer utilizzano uno stile diverso per le specifiche di ora e data rispetto al formato utilizzato in crontab. È più flessibile di crontab e consente date e orari sfocati alla maniera del at comando. Dovrebbe anche essere abbastanza familiare da essere facile da capire.
Il formato di base per i timer di sistema che utilizzano OnCalendar= è DOW YYYY-MM-DD HH:MM:SS . DOW (giorno della settimana) è facoltativo e altri campi possono utilizzare un asterisco (*) per abbinare qualsiasi valore per quella posizione. Tutti i moduli dell'ora del calendario vengono convertiti in un modulo normalizzato. Se l'ora non è specificata, si presume che sia 00:00:00. Se la data non è specificata ma lo è l'ora, la prossima partita potrebbe essere oggi o domani, a seconda dell'ora corrente. È possibile utilizzare nomi o numeri per il mese e il giorno della settimana. È possibile specificare elenchi separati da virgole di ciascuna unità. Gli intervalli di unità possono essere specificati con .. tra il valore iniziale e quello finale.
Ci sono un paio di opzioni interessanti per specificare le date. La Tilde (~) può essere utilizzata per specificare l'ultimo giorno del mese o un numero specificato di giorni prima dell'ultimo giorno del mese. La "/" può essere utilizzata per specificare un giorno della settimana come modificatore.
Ecco alcuni esempi di alcune specifiche temporali tipiche utilizzate in OnCalendar dichiarazioni.
| Specifica dell'evento del calendario | Descrizione |
|---|---|
| DOW AAAA-MM-GG HH:MM:SS | |
| *-*-* 00:15:30 | Ogni giorno di ogni mese di ogni anno a 15 minuti e 30 secondi dopo la mezzanotte |
| Settimanale | Ogni lunedì alle 00:00:00 |
| Lun *-*-* 00:00:00 | Come settimanale |
| Lun | Come settimanale |
| Mer 2020-*-* | Ogni mercoledì nel 2020 alle 00:00:00 |
| Lun..Ven 2021-*-* | Tutti i giorni feriali nel 2021 alle 00:00:00 |
| 2022-6,7,8-1,15 01:15:00 | Il 1° e il 15 giugno, luglio e agosto 2022 alle 01:15:00 |
| Lun *-05~03 | L'occorrenza successiva di un lunedì di maggio di qualsiasi anno che è anche il terzo giorno dalla fine del mese. |
| Lun..Ven *-08~04 | Il 4° giorno che precede la fine di agosto per tutti gli anni in cui cade anche un giorno feriale. |
| *-05~03/2 | Il 3° giorno dalla fine del mese di maggio e poi di nuovo due giorni dopo. Si ripete ogni anno. Nota che questa espressione usa la Tilde (~). |
| *-05-03/2 | Il terzo giorno del mese di maggio e poi ogni 2° giorno per il resto di maggio. Si ripete ogni anno. Nota che questa espressione usa il trattino (-). |
Tabella 2:OnCalendar di esempio specifiche dell'evento
Test delle specifiche del calendario
systemd fornisce uno strumento eccellente per convalidare ed esaminare le specifiche degli eventi dell'ora del calendario in un timer. Il systemd-analyze calendar lo strumento analizza una specifica dell'evento dell'ora del calendario e fornisce la forma normalizzata, nonché altre informazioni interessanti come la data e l'ora del prossimo "trascorso", ovvero la corrispondenza, e la quantità approssimativa di tempo prima che venga raggiunto il tempo di attivazione.
Per prima cosa, guarda una data futura senza un'ora (nota che i tempi per Next elapse e UTC differirà in base al fuso orario locale):
[student@studentvm1 ~]$ systemd-analyze calendar 2030-06-17
Original form: 2030-06-17
Normalized form: 2030-06-17 00:00:00
Next elapse: Mon 2030-06-17 00:00:00 EDT
(in UTC): Mon 2030-06-17 04:00:00 UTC
From now: 10 years 0 months left
[root@testvm1 system]#
Now add a time. In this example, the date and time are analyzed separately as non-related entities:
[root@testvm1 system]# systemd-analyze calendar 2030-06-17 15:21:16
Original form: 2030-06-17
Normalized form: 2030-06-17 00:00:00
Next elapse: Mon 2030-06-17 00:00:00 EDT
(in UTC): Mon 2030-06-17 04:00:00 UTC
From now: 10 years 0 months left
Original form: 15:21:16
Normalized form: *-*-* 15:21:16
Next elapse: Mon 2020-06-15 15:21:16 EDT
(in UTC): Mon 2020-06-15 19:21:16 UTC
From now: 3h 55min left
[root@testvm1 system]#
To analyze the date and time as a single unit, enclose them together in quotes. Be sure to remove the quotes when using them in the OnCalendar= event specification in a timer unit or you will get errors:
[root@testvm1 system]# systemd-analyze calendar "2030-06-17 15:21:16"
Normalized form: 2030-06-17 15:21:16
Next elapse: Mon 2030-06-17 15:21:16 EDT
(in UTC): Mon 2030-06-17 19:21:16 UTC
From now: 10 years 0 months left
[root@testvm1 system]#
Now test the entries in Table 2. I like the last one, especially:
[root@testvm1 system]# systemd-analyze calendar "2022-6,7,8-1,15 01:15:00"
Original form: 2022-6,7,8-1,15 01:15:00
Normalized form: 2022-06,07,08-01,15 01:15:00
Next elapse: Wed 2022-06-01 01:15:00 EDT
(in UTC): Wed 2022-06-01 05:15:00 UTC
From now: 1 years 11 months left
[root@testvm1 system]#
Let’s look at one example in which we list the next five elapses for the timestamp expression.
[root@testvm1 ~]# systemd-analyze calendar --iterations=5 "Mon *-05~3"
Original form: Mon *-05~3
Normalized form: Mon *-05~03 00:00:00
Next elapse: Mon 2023-05-29 00:00:00 EDT
(in UTC): Mon 2023-05-29 04:00:00 UTC
From now: 2 years 11 months left
Iter. #2: Mon 2028-05-29 00:00:00 EDT
(in UTC): Mon 2028-05-29 04:00:00 UTC
From now: 7 years 11 months left
Iter. #3: Mon 2034-05-29 00:00:00 EDT
(in UTC): Mon 2034-05-29 04:00:00 UTC
From now: 13 years 11 months left
Iter. #4: Mon 2045-05-29 00:00:00 EDT
(in UTC): Mon 2045-05-29 04:00:00 UTC
From now: 24 years 11 months left
Iter. #5: Mon 2051-05-29 00:00:00 EDT
(in UTC): Mon 2051-05-29 04:00:00 UTC
From now: 30 years 11 months left
[root@testvm1 ~]#
This should give you enough information to start testing your OnCalendar time specifications. The systemd-analyze tool can be used for other interesting analyses, which I will begin to explore in the next article in this series.
Summary
systemd timers can be used to perform the same kinds of tasks as the cron tool but offer more flexibility in terms of the calendar and monotonic time specifications for triggering events.
Even though the service unit you created for this experiment is usually triggered by the timer, you can also use the systemctl start myMonitor.service command to trigger it at any time. Multiple maintenance tasks can be scripted in a single timer; these can be Bash scripts or Linux utility programs. You can run the service triggered by the timer to run all the scripts, or you can run individual scripts as needed.
I will explore systemd's use of time and time specifications in much more detail in the next article.
I have not yet seen any indication that cron and at will be deprecated. I hope that does not happen because at , at least, is much easier to use for one-off task scheduling than systemd timers.
Resources
There is a great deal of information about systemd available on the internet, but much is terse, obtuse, or even misleading. In addition to the resources mentioned in this article, the following webpages offer more detailed and reliable information about systemd startup.
- The Fedora Project has a good, practical guide to systemd. It has pretty much everything you need to know in order to configure, manage, and maintain a Fedora computer using systemd.
- The Fedora Project also has a good cheat sheet that cross-references the old SystemV commands to comparable systemd ones.
- For detailed technical information about systemd and the reasons for creating it, check out Freedesktop.org's description of systemd.
- Linux.com's "More systemd fun" offers more advanced systemd information and tips.
There is also a series of deeply technical articles for Linux sysadmins by Lennart Poettering, the designer and primary developer of systemd. These articles were written between April 2010 and September 2011, but they are just as relevant now as they were then. Much of everything else good that has been written about systemd and its ecosystem is based on these papers.
- Rethinking PID 1
- systemd for Administrators, Part I
- systemd for Administrators, Part II
- systemd for Administrators, Part III
- systemd for Administrators, Part IV
- systemd for Administrators, Part V
- systemd for Administrators, Part VI
- systemd for Administrators, Part VII
- systemd for Administrators, Part VIII
- systemd for Administrators, Part IX
- systemd for Administrators, Part X
- systemd for Administrators, Part XI