Právě převádím své úlohy cron na časovače systemd. Používám časovače několik let, ale obvykle jsem se naučil právě tolik, abych mohl provést úkol, na kterém jsem pracoval. Při výzkumu této série systemd jsem zjistil, že časovače systemd mají některé velmi zajímavé schopnosti.
Stejně jako úlohy cron mohou časovače systemd spouštět události – skripty shellu a programy – ve stanovených časových intervalech, například jednou denně, v určitý den v měsíci (možná pouze pokud je pondělí) nebo každých 15 minut během pracovní doby. od 8 do 18 hodin. Časovače mohou také dělat některé věci, které úlohy cronu nemohou. Časovač může například spustit skript nebo program, aby se spustil po určitou dobu po události, jako je spuštění, spuštění, dokončení předchozí úlohy nebo dokonce předchozí dokončení servisní jednotky volané časovačem.
Časovače údržby systému
Když je Fedora nebo jakákoli distribuce založená na systemd nainstalována na nový systém, vytvoří několik časovačů, které jsou součástí procedur údržby systému, které se dějí na pozadí libovolného hostitele Linuxu. Tyto časovače spouštějí události nezbytné pro běžné úkoly údržby, jako je aktualizace systémových databází, čištění dočasných adresářů, rotace souborů protokolu a další.
Jako příklad se podívám na některé časovače na mé primární pracovní stanici pomocí systemctl status *timer příkaz k zobrazení seznamu všech časovačů na mém hostiteli. Symbol hvězdičky funguje stejně jako pro globování souborů, takže tento příkaz uvádí všechny jednotky časovače systemd:
[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.
Ke každému časovači je přidruženo alespoň šest řádků informací:
- První řádek obsahuje název souboru časovače a krátký popis jeho účelu.
- Druhý řádek zobrazuje stav časovače, zda je načten, úplnou cestu k souboru jednotky časovače a předvolbu dodavatele.
- Třetí řádek označuje jeho aktivní stav, který zahrnuje datum a čas, kdy se časovač stal aktivním.
- Čtvrtý řádek obsahuje datum a čas dalšího spuštění časovače a přibližný čas do spuštění.
- Pátý řádek zobrazuje název události nebo služby, která je spuštěna časovačem.
- Některé (ale ne všechny) soubory systemd unit obsahují odkazy na příslušnou dokumentaci. Tři z časovačů ve výstupu mého virtuálního stroje mají ukazatele na dokumentaci. Toto je pěkný (ale volitelný) kousek dat.
- Poslední řádek je záznam deníku pro nejnovější instanci služby spuštěnou časovačem.
V závislosti na vašem hostiteli budete pravděpodobně mít jinou sadu časovačů.
Vytvořte časovač
Přestože můžeme dekonstruovat jeden nebo více existujících časovačů, abychom se naučili, jak fungují, vytvořme si vlastní servisní jednotku a jednotku časovače, která je spustí. Aby to bylo jednoduché, použijeme docela triviální příklad. Až to dokončíme, bude snazší porozumět tomu, jak fungují ostatní časovače, a určit, co dělají.
Nejprve vytvořte jednoduchou službu, která bude provozovat něco základního, například free příkaz. Můžete například chtít v pravidelných intervalech sledovat volnou paměť. Vytvořte následující myMonitor.service soubor jednotky v /etc/systemd/system adresář. Nemusí být spustitelný:
# 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
Nyní se podíváme na stav a otestujeme naši servisní jednotku, abychom se ujistili, že funguje tak, jak očekáváme.
[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]#
Kde je výstup? Ve výchozím nastavení je standardní výstup (STDOUT ) z programů provozovaných servisními jednotkami systemd se odesílá do žurnálu systemd, který zanechává záznam, který si můžete prohlédnout nyní nebo později – až do určitého bodu. (Na systemd žurnálování a strategie uchovávání se podívám v budoucím článku této série.) Podívejte se na žurnál speciálně pro vaši servisní jednotku a pouze pro dnešek. -S option, což je zkrácená verze --since , umožňuje zadat časové období, po které journalctl nástroj by měl vyhledávat záznamy. Není to proto, že by vás nezajímaly předchozí výsledky – v tomto případě žádné nebudou – jde o zkrácení doby hledání, pokud váš hostitel běží dlouhou dobu a nashromáždil velké množství záznamů. v deníku:
[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]#
Úlohou spuštěnou službou může být jeden program, řada programů nebo skript napsaný v libovolném skriptovacím jazyce. Přidejte do služby další úkol přidáním následujícího řádku na konec [Service] části myMonitor.service soubor jednotky:
ExecStart=/usr/bin/lsblkSpusťte službu znovu a zkontrolujte výsledky v deníku, který by měl vypadat takto. Výsledky obou příkazů byste měli vidět v deníku:
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.
Nyní, když víte, že vaše služba funguje podle očekávání, vytvořte soubor jednotky časovače myMonitor.timer v /etc/systemd/system a přidejte následující:
# 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
OnCalendar specifikaci času v myMonitor.timer file , *-*-* *:*:00 , by měl spustit časovač ke spuštění myMonitor.service jednotku každou minutu. Prozkoumám OnCalendar nastavení o něco později v tomto článku.
Prozatím sledujte všechny položky deníku týkající se spuštění vaší služby, když je spuštěna časovačem. Můžete také sledovat časovač, ale sledování služby vám umožní vidět výsledky téměř v reálném čase. Spusťte journalctl pomocí -f (následovat) možnost:
[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --
Spusťte, ale nepovolujte časovač, a uvidíte, co se stane, když chvíli běží:
[root@testvm1 ~]# systemctl start myMonitor.service
[root@testvm1 ~]#
Jeden výsledek se objeví hned a další přicházejí v – tak nějak – minutových intervalech. Sledujte deník několik minut a zjistěte, zda si všimnete stejných věcí jako já:
[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.
Nezapomeňte zkontrolovat stav časovače i služby.
Více o sysadmins
- Povolit blog Sysadmin
- Automatizovaný podnik:průvodce řízením IT pomocí automatizace
- eKniha:Ansible Automation for SysAdmins
- Příběhy z terénu:Průvodce správcem systému pro automatizaci IT
- eKniha:Průvodce Kubernetes pro SRE a správce systému
- Nejnovější články správce systému
Pravděpodobně jste si v deníku všimli alespoň dvou věcí. Za prvé, nemusíte dělat nic zvláštního, abyste způsobili STDOUT z ExecStart spouští v myMonitor.service jednotka, která se má uložit do deníku. To vše je součástí používání systemd pro spouštění služeb. Znamená to však, že možná budete muset být opatrní při spouštění skriptů ze servisní jednotky a jak moc STDOUT generují.
Druhá věc je, že časovač se nespustí přesně na minutu v :00 sekund nebo dokonce přesně jednu minutu od předchozí instance. Toto je záměrné, ale v případě potřeby to lze přepsat (nebo pokud to jen uráží vaše cítění systémového správce).
Důvodem tohoto chování je zabránit spouštění více služeb ve stejnou dobu. Můžete například použít časové specifikace, jako je Týdně, Denně a další. Všechny tyto zkratky jsou definovány tak, aby se spouštěly v 00:00:00 hodin v den, kdy byly spuštěny. Když je takto specifikováno více časovačů, existuje velká pravděpodobnost, že by se pokusily spustit současně.
Časovače systemd jsou záměrně navrženy tak, aby se spouštěly poněkud náhodně kolem zadaného času, aby se zabránilo simultánním spouštěním. Spouštějí se polonáhodně v rámci časového okna, které začíná v určený čas spuštění a končí v určený čas plus jedna minuta. Tato doba spouštění je udržována na stabilní pozici s ohledem na všechny ostatní definované jednotky časovače podle systemd.timer manuálová stránka. Ve výše uvedených záznamech deníku můžete vidět, že časovač se spustil okamžitě, když začal, a poté asi 46 nebo 47 sekund po každé minutě.
Většinou jsou takovéto pravděpodobnostní spouštěcí časy v pořádku. Při plánování spouštění úloh, jako je zálohování, nebudou žádné problémy, pokud budou probíhat mimo pracovní dobu. Systémový správce může vybrat deterministický čas spuštění, například 01:05:00 v typické specifikaci úlohy cron, aby nebyl v rozporu s jinými úkoly, ale existuje velký rozsah časových hodnot, které toho dosáhnou. Minutová náhoda v počátečním čase je obvykle irelevantní.
U některých úloh jsou však přesné časy spouštění absolutním požadavkem. Pro ty můžete zadat větší přesnost časového rozpětí spouštění (v rámci mikrosekundy) přidáním příkazu jako je tento do Timer sekce souboru jednotky časovače:
AccuracySec=1usČasová rozpětí lze použít k určení požadované přesnosti a také k definování časových rozpětí pro opakující se nebo jednorázové události. Rozpoznává následující jednotky:
- usec, us, µs
- msec, ms
- sekundy, sekundy, sekundy, s
- minuty, minuty, min, m
- hodiny, hodiny, hodiny, h
- dny, den, d
- týdny, týden, w
- měsíce, měsíce, M (definováno jako 30,44 dne)
- roky, rok, y (definováno jako 365,25 dne)
Všechny výchozí časovače v /usr/lib/systemd/system specifikujte mnohem větší rozsah pro přesnost, protože přesné časy nejsou kritické. Podívejte se na některé specifikace v časovačích vytvořených systémem:
[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]#
Zobrazit úplný obsah některých souborů jednotek časovače v /usr/lib/systemd/system adresář, abyste viděli, jak jsou konstruovány.
V tomto experimentu nemusíte povolit časovač, abyste jej aktivovali při spouštění, ale příkaz k tomu bude:
# systemctl enable myMonitor.timerSoubory jednotek, které jste vytvořili, nemusí být spustitelné. Také jste nepovolili servisní jednotku, protože ji spouští časovač. Pokud chcete, stále můžete servisní jednotku spustit ručně z příkazového řádku. Zkuste to a sledujte deník.
Podívejte se na manuálové stránky pro systemd.timer a systemd.time pro více informací o přesnosti časovače, specifikacích času události a spouštěcích událostech.
Typy časovačů
Časovače systemd mají další schopnosti, které nenajdete v cronu, který se spouští pouze v konkrétních, opakujících se datech a časech v reálném čase. Časovače systemd lze nakonfigurovat tak, aby se spouštěly na základě změn stavu v jiných jednotkách systemd. Časovač může být například nakonfigurován tak, aby spustil konkrétní uplynulý čas po spuštění systému, po spuštění nebo po aktivaci definované servisní jednotky. Tyto časovače se nazývají monotónní. Monotónní označuje počet nebo sekvenci, která se neustále zvyšuje. Tyto časovače nejsou trvalé, protože se resetují po každém spuštění.
Tabulka 1 uvádí monotónní časovače spolu s krátkou definicí každého z nich a také OnCalendar časovač, který není monotónní a používá se ke specifikaci budoucích časů, které se mohou nebo nemusí opakovat. Tyto informace jsou odvozeny z systemd.timer manuálová stránka s několika drobnými změnami.
| Časovač | Monotónní | Definice |
|---|---|---|
OnActiveSec= | X | Toto definuje časovač vzhledem k okamžiku, kdy je časovač aktivován. |
OnBootSec= | X | Toto definuje časovač vzhledem k tomu, kdy se počítač spouští. |
OnStartupSec= | X | Toto definuje časovač vzhledem k prvnímu spuštění správce služeb. U jednotek systémového časovače je to velmi podobné OnBootSec= , protože správce systémových služeb obvykle začíná velmi brzy při startu. Je to užitečné především při konfiguraci v jednotkách spuštěných ve správci služeb pro uživatele, protože správce služeb pro uživatele se obvykle spouští pouze při prvním přihlášení, nikoli během spouštění. |
OnUnitActiveSec= | X | Toto definuje časovač vzhledem k tomu, kdy byl časovač, který se má aktivovat, naposledy aktivován. |
OnUnitInactiveSec= | X | Toto definuje časovač vzhledem k tomu, kdy byl časovač, který se má aktivovat, naposledy deaktivován. |
OnCalendar= | Toto definuje časovače v reálném čase (tj. nástěnné hodiny) s výrazy událostí kalendáře. Viz systemd.time(7) Další informace o syntaxi výrazů událostí kalendáře. Jinak je sémantika podobná OnActiveSec= a související nastavení. Tento časovač je nejvíce podobný těm, které se používají se službou cron. |
Tabulka 1:Definice systémových časovačů
Monotónní časovače mohou pro svá časová rozpětí používat stejné názvy zkratek jako AccuracySec dříve zmíněný příkaz, ale systemd normalizuje tato jména na sekundy. Můžete například chtít zadat časovač, který spustí událost jednou, pět dní po zavedení systému; může to vypadat takto:OnBootSec=5d . Pokud se hostitel spustil v 2020-06-15 09:45:27 , časovač se spustí v 2020-06-20 09:45:27 nebo do jedné minuty poté.
Specifikace události kalendáře
Specifikace událostí kalendáře jsou klíčovou součástí spouštění časovačů v požadovaných opakujících se časech. Začněte tím, že se podíváte na některé specifikace používané s OnCalendar nastavení.
systemd a jeho časovače používají jiný styl pro specifikace času a data než formát používaný v crontab. Je flexibilnější než crontab a umožňuje fuzzy data a časy způsobem at příkaz. Mělo by být také dostatečně známé, aby bylo snadno pochopitelné.
Základní formát pro časovače systemd pomocí OnCalendar= je DOW YYYY-MM-DD HH:MM:SS . DOW (den v týdnu) je volitelný a ostatní pole mohou používat hvězdičku (*), aby odpovídala jakékoli hodnotě pro danou pozici. Všechny formuláře kalendářního času jsou převedeny do normalizované formy. Pokud není čas specifikován, předpokládá se, že je 00:00:00. Pokud datum není zadáno, ale čas ano, další zápas může být dnes nebo zítra, v závislosti na aktuálním čase. Pro měsíc a den v týdnu lze použít jména nebo čísla. Lze zadat seznamy jednotlivých jednotek oddělené čárkami. Rozsahy jednotek lze zadat pomocí .. mezi počáteční a koncovou hodnotou.
Existuje několik zajímavých možností pro určení data. Vlnovku (~) lze použít k určení posledního dne v měsíci nebo zadaného počtu dní před posledním dnem v měsíci. Znak „/“ lze použít k určení dne v týdnu jako modifikátoru.
Zde je několik příkladů typických časových specifikací používaných v OnCalendar prohlášení.
| Specifikace události kalendáře | Popis |
|---|---|
| DOW YYYY-MM-DD HH:MM:SS | |
| *-*-* 00:15:30 | Každý den každého měsíce každého roku 15 minut a 30 sekund po půlnoci |
| Týdně | Každé pondělí v 00:00:00 |
| Po *-*-* 00:00:00 | Stejné jako týdně |
| Po | Stejné jako týdně |
| St 2020-*-* | Každou středu v roce 2020 v 00:00:00 |
| Po..Pá 2021-*-* | Každý všední den v roce 2021 v 00:00:00 |
| 2022-6,7,8-1,15 01:15:00 | 1. a 15. června, července a srpna 2022 v 01:15:00 |
| Po *-05~03 | Další výskyt pondělí v květnu kteréhokoli roku, což je také 3. den od konce měsíce. |
| Po..Pá *-08~04 | Čtvrtý den předcházející konci srpna pro všechny roky, ve kterých také připadá na pracovní den. |
| *-05~03/2 | Třetí den od konce měsíce května a poté znovu o dva dny později. Opakuje se každý rok. Všimněte si, že tento výraz používá vlnovku (~). |
| *-05-03/2 | Třetí den v měsíci květnu a poté každý 2. den po zbytek května. Opakuje se každý rok. Všimněte si, že tento výraz používá pomlčku (-). |
Tabulka 2:Ukázka OnCalendar specifikace události
Specifikace testovacího kalendáře
systemd poskytuje vynikající nástroj pro ověřování a zkoumání specifikací kalendářních časových událostí v časovači. systemd-analyze calendar nástroj analyzuje specifikaci časové události kalendáře a poskytuje normalizovanou formu a také další zajímavé informace, jako je datum a čas příštího „uběhnutí“, tj. shody, a přibližné množství času před dosažením času spuštění.
Nejprve se podívejte na datum v budoucnosti bez času (všimněte si, že časy pro Next elapse a UTC se bude lišit podle vašeho místního časového pásma):
[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]#
Nyní přidejte čas. V tomto příkladu jsou datum a čas analyzovány samostatně jako nesouvisející entity:
[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. 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.
Zdroje
Na internetu je k dispozici velké množství informací o systemd, ale mnohé jsou stručné, tupé nebo dokonce zavádějící. In addition to the resources mentioned in this article, the following webpages offer more detailed and reliable information about systemd startup.
- Projekt Fedora má dobrého praktického průvodce systemd. Obsahuje téměř vše, co potřebujete vědět, abyste mohli nakonfigurovat, spravovat a udržovat počítač Fedora pomocí systemd.
- Projekt Fedora má také dobrý cheat sheet, který křížově odkazuje na staré příkazy SystemV se srovnatelnými příkazy systemd.
- Podrobné technické informace o systemd a důvodech pro jeho vytvoření naleznete v popisu systemd na Freedesktop.org.
- Pokročilejší systémové informace a tipy nabízí stránka Linux.com „More systemd fun“.
Existuje také řada hluboce technických článků pro správce systému Linux od Lennarta Poetteringa, návrháře a primárního vývojáře systemd. Tyto články byly napsány mezi dubnem 2010 a zářím 2011, ale nyní jsou stejně aktuální jako tehdy. Většina všeho dobrého, co bylo napsáno o systemd a jeho ekosystému, je založeno na těchto dokumentech.
- Přehodnocení PID 1
- systemd pro administrátory, část I
- systemd pro administrátory, část II
- systemd pro administrátory, část III
- systemd pro administrátory, část IV
- systemd pro administrátory, část V
- systemd pro administrátory, část VI
- systemd pro administrátory, část VII
- systemd pro administrátory, část VIII
- systemd pro administrátory, část IX
- systemd pro administrátory, část X
- systemd pro administrátory, část XI