Clever Geek Handbook

Verwenden von Systemd-Timern anstelle von Cron-Jobs

Ich bin gerade dabei, meine Cron- Jobs durch System-Timer zu ersetzen . Ich benutze Timer seit mehreren Jahren, aber normalerweise ging ich nicht tief in die Feinheiten ihrer Verwendung ein und fand nur heraus, was nötig war, um die fĂŒr mich interessante Aufgabe zu erfĂŒllen. Ich habe kĂŒrzlich an einer Reihe von Artikeln ĂŒber systemd gearbeitet und herausgefunden, dass systemd-Timer einige sehr interessante Funktionen haben.







Diese Timer können wie Cron-Jobs zu einem bestimmten Zeitpunkt verschiedene Aktionen im System auslösen. Zum Beispiel - AusfĂŒhren von Shell-Skripten oder -Programmen. Timer können beispielsweise einmal am Tag und nur montags arbeiten. Ein weiteres Beispiel ist ein Timer, der wĂ€hrend der GeschĂ€ftszeiten (von 8 bis 18 Uhr) alle 15 Minuten ausgelöst wird. Systemd-Timer können jedoch etwas tun, was Cron-Jobs nicht können. Ein Timer kann beispielsweise ein Skript aufrufen oder eine bestimmte Zeit nach einem Ereignis programmieren. Ein solches Ereignis kann der Systemstart oder der Systemstart, der Abschluss einer vorherigen Aufgabe oder sogar die Beendigung eines Dienstes sein, der zuvor von einem Zeitgeber aufgerufen wurde.



Timer fĂŒr die Systemwartung



Wenn Fedora oder eine andere systembasierte Linux-Distribution auf einem Computer installiert ist, werden im Rahmen der Wartungsroutinen des Systems mehrere Timer erstellt. Diese Verfahren werden automatisch auf jedem Linux-System ausgefĂŒhrt. Die entsprechenden Zeitgeber lösen verschiedene Serviceaufgaben aus, z. B. das Aktualisieren von Systemdatenbanken, das Löschen temporĂ€rer Verzeichnisse, das Drehen von Protokolldateien usw.



Als Beispiel werde ich hier Informationen zu den Timern geben, die auf der virtuellen Maschine verfĂŒgbar sind, die ich fĂŒr Experimente verwendet habe. Um eine Liste aller Timer zu erhalten, habe ich den Befehl verwendetsystemctl status *timer... Der Sternchen-Platzhalter spielt hier die gleiche Rolle wie bei anderen Ă€hnlichen Befehlen. Es teilt dem System nĂ€mlich mit, dass wir an allen Timern (Timer-Einheiten, sie werden auch als "Timer-Einheitendateien" oder "Timer-Einheiten" bezeichnet) von systemd interessiert sind: 



[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.


Jedem Timer sind mindestens sechs Zeilen zugeordnet, die Informationen darĂŒber enthalten:



  • Die erste Zeile enthĂ€lt den Namen der Timer-Datei und eine kurze Beschreibung des Zwecks der Existenz des Timers.
  • In der zweiten Zeile werden Informationen zum Status des Timers angezeigt. Es wird nĂ€mlich gemeldet, ob es geladen ist, der vollstĂ€ndige Pfad zur Timer-Datei angegeben und der Status der Hersteller-Voreinstellung (deaktiviert oder aktiviert) angezeigt.
  • Die dritte Zeile enthĂ€lt Informationen zur AktivitĂ€t des Timers, einschließlich Informationen darĂŒber, wann der Timer aktiviert wurde.
  • Die vierte Zeile enthĂ€lt das Datum und die Uhrzeit des nĂ€chsten Starts des Timers sowie die ungefĂ€hre verbleibende Zeit bis zum Start.
  • Die fĂŒnfte Zeile gibt den Namen des vom Timer aufgerufenen Dienstes oder Ereignisses an.
  • Einige (aber nicht alle) systemd-Timer-Unit-Dateien enthalten Zeiger auf die Dokumentation. Solche Zeiger finden sich in meinem Beispiel in den Beschreibungen von drei Timern.
  • Die letzte Zeile in der Timer-Beschreibung ist der Protokolleintrag, der der letzten vom Timer aufgerufenen Instanz des Dienstes zugeordnet ist.


Wenn Sie versuchen, einen Befehl auf Ihrem Computer auszufĂŒhren systemctl status *timer, können sich die ihm prĂ€sentierten Timer von meinen unterscheiden.



Timer-Erstellung



Obwohl wir die Besonderheiten der Funktionsweise von Timern durch Analyse vorhandener Timer herausfinden könnten, empfehle ich, eine eigene Serviceeinheitendatei (Servicekonfigurationsdatei, Serviceeinheit ) und eine Timerdatei zu erstellen, mit der der entsprechende Service aufgerufen wird. Wir sind hier, um die Geschichte nicht zu komplizieren, geben wir ein eher triviales Beispiel. Aber nachdem wir uns damit befasst haben, wird es fĂŒr Sie einfacher sein, die Arbeit anderer Timer zu verstehen.



Lassen Sie uns zunĂ€chst eine einfache Dienstkonfigurationsdatei erstellen, die so einfach wie ein Befehl ausgefĂŒhrt wird free. Dies kann beispielsweise erforderlich sein, wenn die Menge des freien Speichers regelmĂ€ĂŸig ĂŒberwacht werden muss. Erstellen wir eine Einheitendatei mit dem Namen myMonitor.serviceim Ordner /etc/systemd/system. Es muss nicht ausfĂŒhrbar sein. 



# 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


Diese Datei ist wahrscheinlich die einfachste Dienstkonfigurationsdatei. Lassen Sie uns nun den Status ĂŒberprĂŒfen und testen, um sicherzustellen, dass er wie erwartet funktioniert. 



[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]#


Warum wird nichts an die Konsole ausgegeben? Dies liegt daran, dass die Standardausgabe ( stdout) von Programmen, die von systemd mithilfe von Service Unit-Dateien gestartet wurden , standardmĂ€ĂŸig in das systemd-Protokoll umgeleitet wird. Aus diesem Grund können diese DatensĂ€tze analysiert werden, solange die entsprechenden DatensĂ€tze vorhanden sind. Werfen wir einen Blick in das Protokoll und suchen nach EintrĂ€gen in Bezug auf unseren Service und den Tag, an dem wir getestet haben. Der entsprechende Befehl sieht folgendermaßen aus : journalctl -S today -u myMonitor.service. Der SchlĂŒssel -Sist eine abgekĂŒrzte Version --since. Hier können Sie den Zeitraum angeben, fĂŒr den das Dienstprogramm ausgefĂŒhrt wirdjournalctlauf der Suche nach Aufzeichnungen. Der Punkt ist nicht, dass wir nicht an frĂŒheren Ergebnissen interessiert sind. In unserem Fall werden solche Ergebnisse einfach nicht sein. Dieser SchlĂŒssel wird verwendet, um die Zeit zu verkĂŒrzen, die das Dienstprogramm fĂŒr die Suche nach Daten benötigt. Wenn der Computer lĂ€ngere Zeit funktioniert hat, können sich viele EintrĂ€ge im Protokoll ansammeln. 



[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]#


Eine Aufgabe, die mithilfe einer Dienstkonfigurationsdatei gestartet wird, kann als einzelnes Programm, als Programmsequenz oder als Skript in einer beliebigen Skriptsprache dargestellt werden. FĂŒgen wir der Einheitendatei eine myMonitor.serviceweitere Aufgabe hinzu, einschließlich der [Service]folgenden am Ende des Abschnitts : 



ExecStart=/usr/bin/lsblk


Lassen Sie uns den Dienst erneut starten und das Protokoll ĂŒberprĂŒfen. Es sollte etwas drin sein, das dem Ă€hnelt, was unten gezeigt wird. Das Protokoll sollte nĂ€mlich die von beiden Befehlen ausgegebenen Daten enthalten: 



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.


Nachdem wir sicher sind, dass alles ordnungsgemĂ€ĂŸ funktioniert, erstellen wir im Ordner /etc/systemd/systemeine Timer-Einheitendatei, die einen Namen erhĂ€lt myMonitor.timer. FĂŒgen Sie der Datei Folgendes hinzu: 



# 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


Der Zeitstempel OnCalendarin dieser Datei *-*-* *:*:00sollte dazu fĂŒhren , dass der Timer das GerĂ€t myMonitor.servicejede Minute anruft. OnCalendarWir werden weiter unten mehr darĂŒber sprechen.



In der Zwischenzeit können wir uns die ProtokolleintrĂ€ge zum Starten des Timer-Dienstes ansehen. Wir können auch den Timer-Überwachungsmodus aktivieren. Durch die Überwachung des Dienstes können Sie die Ergebnisse jedoch nahezu in Echtzeit anzeigen. Dazu mĂŒssen Sie journalctlmit dem SchlĂŒssel -f( follow) ausfĂŒhren : 



[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --


Starten Sie den Timer, nehmen Sie ihn jedoch beim Systemstart nicht in den Autostart auf.  



[root@testvm1 ~]# systemctl start myMonitor.timer
[root@testvm1 ~]#


Beobachten Sie, was fĂŒr eine Weile passiert.



Eines der Ergebnisse erscheint sofort. Die nÀchsten werden in AbstÀnden von etwa einer Minute angezeigt. Sehen Sie sich das Magazin einige Minuten lang an. 



[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.


ÜberprĂŒfen Sie sowohl den Timer-Status als auch den Servicestatus.



Haben Sie hier bemerkt, was mir aufgefallen ist? Möglicherweise haben Sie beim Lesen der Zeitschrift mindestens zwei Dinge bemerkt.



Erstens - die Tatsache , dass Sie nicht etwas Besonderes zu tun , fĂŒr die Anmeldung mĂŒssen , dass ExecStartdie myMonitor.servicein schriftlicher Form stdout. Diese Funktion ist Teil der Standard-Systemd-Startfunktionen. Dies bedeutet jedoch, dass Sie wahrscheinlich vorsichtig sein mĂŒssen, wenn Sie Skripts aus Dienstkonfigurationsdateien ausfĂŒhren und notieren, in wie viele Daten sie schreiben stdout.



Zweitens haben Sie möglicherweise bemerkt, dass der Timer nicht genau um startet:00Sekunden jeder Minute und nicht einmal genau eine Minute nach dem letzten Lauf. Dies ist eine der Funktionen solcher Timer. Wenn dies erforderlich ist (oder wenn dies die GefĂŒhle des Systemadministrators verletzt), kann dieses Verhalten der Timer geĂ€ndert werden, indem sie genauer gemacht werden.



Der Grund dafĂŒr, dass der Timer nicht in :00Sekunden jeder Minute startet, liegt darin, dass das System dazu neigt, zu verhindern, dass mehrere Dienste gleichzeitig gestartet werden. Wenn zum Beispiel der Zeitanzeige einrichten, OnCalendarkönnen Sie Werte wie verwenden Weekly, Dailyund andere. Diese kurzen Arten der Benennung von Zeiten sind so eingerichtet, dass die Timer, in denen sie verwendet werden, beginnen00:00:00der entsprechende Tag. Wenn mehrere Timer auf diese Weise konfiguriert werden, ist die Wahrscheinlichkeit hoch, dass alle gleichzeitig ausgelöst werden.



Aus diesem Grund sind systemd-Timer bewusst so konzipiert, dass sie nicht genau zum angegebenen Zeitpunkt starten, sondern mit einer zufĂ€lligen Abweichung davon. Diese Abweichung kann nicht als völlig zufĂ€llig bezeichnet werden. Timer beginnen irgendwo in einem Zeitfenster, das zum angegebenen Zeitpunkt beginnt und eine Minute nach dem Original endet. Diese Zeit wird gemĂ€ĂŸ der Dokumentation fĂŒr systemd.timerunter BerĂŒcksichtigung aller anderen im System deklarierten Zeitgeber in einem stabilen Zustand gehalten. Im obigen Protokollfragment können Sie sehen, dass der Timer unmittelbar nach dem Start ausgelöst wird und dann - ungefĂ€hr 46 oder 47 Sekunden nach dem Start jeder nĂ€chsten Minute.



Am hĂ€ufigsten passt ein solcher probabilistischer Ansatz zur Bestimmung des genauen Timings der Timer zu jedem. Wenn Sie Aufgaben planen, z. B. eine Sicherungskopie erstellen, wĂ€hrend solche Aufgaben außerhalb der GeschĂ€ftszeiten ausgefĂŒhrt werden, verursacht dies keine Probleme. Der Systemadministrator, der Cron-Jobs einrichtet, kann klar definierte Startzeiten festlegen, z. B. 01:05:00um sicherzustellen, dass diese Jobs nicht mit anderen in Konflikt stehen. Es gibt eine Vielzahl von Möglichkeiten, die Zeit anzugeben, die dies zulĂ€sst. ZufĂ€llige Änderungen in der Startzeit einer Aufgabe, die eine Minute nicht ĂŒberschreiten, spielen normalerweise keine besondere Rolle.



Bei einigen Aufgaben ist jedoch das genaue Timing des Timers Ă€ußerst wichtig. In solchen FĂ€llen können Sie beim Einstellen der Timer eine genauere Betriebszeit angeben (bis zu der in Mikrosekunden gemessenen Genauigkeit). Dazu fĂŒgen Sie der Timer-Beschreibungsdatei im Abschnitt Timereine Konstruktion hinzu, die der folgenden Ă€hnelt: 



AccuracySec=1us


Sie können spezielle SchlĂŒsselwörter verwenden, um die gewĂŒnschte Genauigkeit des Timers festzulegen. Diese SchlĂŒsselwörter können auch beim Einrichten von wiederkehrenden und einmaligen Ereignissen verwendet werden. Das System versteht die folgenden SchlĂŒsselwörter:



  • Mikrosekunde: usec, us, ”s.
  • Millisekunde: msec, ms.
  • Zweitens: seconds, second, sec, s.
  • Minute: minutes, minute, min, m.
  • Stunde: hours, hour, hr, h.
  • Tag: days, day, d.
  • Woche: weeks, week, w.
  • Monat: months, month, M(der Monat als 30,44 Tage definiert).
  • Jahr: years, year, y(das Jahr als 365,25 Tage definiert ist).


Alle Standard-Timer, die in verfĂŒgbar /usr/lib/systemd/systemsind, werden mit viel grĂ¶ĂŸeren Bereichen konfiguriert, die die Genauigkeit ihrer Auslösung festlegen, da bei diesen Zeitgebern ihre Auslösung zu einem genau festgelegten Zeitpunkt nicht besonders wichtig ist. Schauen Sie sich die technischen Daten einiger vom System generierter Timer an: 



[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]#


Um die interne Struktur der Timer-Dateien aus dem Verzeichnis besser zu verstehen /usr/lib/systemd/system, können Sie deren Inhalt anzeigen.



Sie mĂŒssen unseren Lern-Timer nicht so konfigurieren, dass er beim Systemstart aktiviert wird. Wenn Sie möchten, können Sie hierfĂŒr den folgenden Befehl verwenden: 



[root@testvm1 system]# systemctl enable myMonitor.timer


Die von Ihnen erstellten Timer-Dateien mĂŒssen nicht ausfĂŒhrbar sein. DarĂŒber hinaus mĂŒssen Dienstkonfigurationsdateien nicht so konfiguriert werden, dass sie beim Booten aktiviert werden, da sie von Timern aufgerufen werden. Bei Bedarf kann der Dienst auch manuell ĂŒber die Befehlszeile aufgerufen werden. Versuchen Sie dies und schauen Sie im Systemd-Protokoll nach.



Weitere Informationen zur Genauigkeit von Timern, zum Festlegen des Zeitpunkts der Ereignisauslösung und zum Auslösen von Ereignissen finden Sie in der Dokumentation zu systemd.timerund systemd.time.



Timer-Typen



Systemd-Timer verfĂŒgen ĂŒber andere Funktionen, die Cron-Jobs nicht haben, "einmalig" oder sich wiederholend, die nur mit Echtzeit- und Echtzeitdaten aufgerufen werden. Systemd-Timer können so konfiguriert werden, dass sie basierend auf Änderungen im Status anderer systemd-Einheiten aufgerufen werden. Beispielsweise kann ein Timer so konfiguriert werden, dass er nach einer bestimmten Zeit nach dem Systemstart, nach der Anmeldung des Benutzers oder nach einer bestimmten Zeit nach dem Aktivieren eines bestimmten Dienstes ausgelöst wird. Diese Timer werden als monoton bezeichnet. Diese Timer werden nach jedem Systemneustart zurĂŒckgesetzt.



Die folgende Tabelle zeigt eine Liste monotoner Timer mit einer kurzen Beschreibung der einzelnen Timer. Es gibt auch eine Beschreibung des Timers.OnCalendarDies ist nicht eintönig und wird in FĂ€llen verwendet, in denen Sie in Zukunft einen einmaligen oder wiederholten Start von etwas organisieren mĂŒssen. Diese Tabelle basiert auf Dokumentation systemd.timer.

Timer Monoton Beschreibung 
OnActiveSec=


X. Die Timer-Betriebszeit wird relativ zum Zeitpunkt der Timer-Aktivierung eingestellt. 
OnBootSec=


X. Der Timer wird relativ zum Zeitpunkt des Systemstarts eingestellt. 
OnStartupSec=


X. . OnBootSec=, . , , , , , . 
OnUnitActiveSec=


X , , , . 
OnUnitInactiveSec=


X , , , . 
OnCalendar=


  . systemd.time(7). OnActiveSec=. — systemd, , cron.


Beim Einrichten von monotonen Timern können dieselben SchlĂŒsselwörter wie oben beschrieben verwendet werden AccuracySec. Es ist jedoch zu beachten, dass systemd die entsprechenden Zeitintervalle in Sekunden umwandelt. Beispielsweise möchten Sie möglicherweise einen Timer festlegen, der fĂŒnf Tage nach dem Systemstart einmal ausgelöst wird. Es könnte wie folgt aussehen : OnBootSec=5d. Wenn der Computer gebootet wurde 2020-06-15auf 09:45:27, wird der Timer startet 2020-06-20bei 09:45:27(oder innerhalb von 1 Minute nach diesem Zeitpunkt).



Beschreibung der Kalenderereignisse



Das Anwenden von Kalenderereignissen ist ein wichtiger Bestandteil der Beschreibung von Timern, die in regelmĂ€ĂŸigen AbstĂ€nden aufgerufen werden. Lassen Sie uns einige der Merkmale solcher Ereignisse untersuchen, die beim Setzen der Zeitanzeige verwendet werden OnCalendar.



Systemd und die entsprechenden Timer verwenden ein anderes Zeit- und Datumsformat als crontab. Dieses Format ist flexibler als das in crontab verwendete. Sie können Datum und Uhrzeit auf vereinfachte Weise im Befehlsstil angeben at. FĂŒr diejenigen, die damit vertraut sind at, sollte es leicht sein, die Einstellungen des System-Timers zu verstehen.



Beim OnCalendar=Einrichten von Timern wird das folgende Grundformat zum Festlegen von Datum und Uhrzeit verwendet: 



DOW YYYY-MM-DD HH:MM:SS


DOW(Wochentag) ist dies ein optionaler Teil des obigen Konstrukts. In anderen Feldern können Sie das Sternchen ( *) verwenden , um jeden Wert darzustellen, der an der Position angezeigt wird, die er einnimmt. Alle Formen der Angabe von Datum und Uhrzeit werden in normalisierte Form umgewandelt. Wenn keine Zeit angegeben ist, wird davon ausgegangen 00:00:00. Wenn das Datum nicht angegeben ist, aber die Uhrzeit angegeben ist, funktioniert der Timer entweder am Tag seines Starts (relativ gesehen "heute") oder am nĂ€chsten Tag ("morgen"). Es hĂ€ngt von der aktuellen Zeit ab. Monate und Wochentage können anhand ihrer Namen benannt werden. Hier können Sie durch Kommas getrennte Wertelisten verwenden. Wertebereiche können durch drei Punkte ( 
) zwischen dem Start- und Endwert des Bereichs getrennt werden.



Bei der Festlegung der Daten stehen uns einige interessante Optionen zur VerfĂŒgung. Somit kann eine Tilde (~) verwendet werden, um den letzten Tag eines Monats oder ein Datum anzugeben, das eine bestimmte Anzahl von Tagen vor dem letzten Tag des Monats liegt. Der SchrĂ€gstrich (/) kann als Modifikator verwendet werden, um den Wochentag anzuzeigen.



Die folgende Tabelle zeigt einige typische Beispiele fĂŒr das in einem Ausdruck verwendete Timing OnCalendar.



Beispiel fĂŒr die PrĂ€sentation eines Kalenderereignisses DOW YYYY-MM-DD HH:MM:SS

Beschreibung 
*-*-* 00:15:30


Jeden Tag eines jeden Monats eines jeden Jahres, 15 Minuten 30 Sekunden nach Mitternacht. 
Weekly


Jeden Montag um 00:00:00. 
Mon *-*-* 00:00:00


Das gleiche wie Weekly. 
Mon


Das gleiche wie Weekly. 
Wed 2020-*-*


Jeden Mittwoch 2020 um 00:00:00. 
Mon..Fri 2021-*-*


Jeden Wochentag im Jahr 2021 um 00:00:00. 
2022-6,7,8-1,15 01:15:00


1. und 15. Juni, Juli und August 2022 01:15:00nach Mitternacht. 
Mon *-05~03


, , , 3 . 
Mon..Fri *-08~04


, 4 , . 
*-05~03/2


3 , , — , . . , ~. 
*-05-03/2


, — . . , (-).


,



Systemd bietet ein großartiges Tool zum ÜberprĂŒfen und ÜberprĂŒfen von Kalenderereignisspezifikationen. Dies ist ein Team systemd-analyze calendar, das Beschreibungen von Kalenderereignissen analysiert und in normalisierter Form prĂ€sentiert. Dieser Befehl enthĂ€lt auch andere interessante Informationen, z. B. das Datum und die Uhrzeit des nĂ€chsten solchen Ereignisses sowie die ungefĂ€hre verbleibende Zeit bis zu diesem Zeitpunkt.



Lassen Sie uns zunĂ€chst einen Blick auf die Spezifikation ĂŒbernehmen, die nur das Datum enthĂ€lt, keine Informationen ĂŒber die Zeit enthalten (beachten Sie, dass die Zeiten in den Feldern Next elapseund (in UTC)unterschiedlich sind, hĂ€ngt dieser Unterschied auf die lokale Zeitzone): 



[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]#


FĂŒgen wir nun der Beschreibung Zeitinformationen hinzu. In diesem Beispiel werden Datum und Uhrzeit getrennt als EntitĂ€ten analysiert, die nicht miteinander verbunden sind: 



[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]#


Betrachten Sie nun ein Beispiel, in dem Datum und Uhrzeit zusammen betrachtet werden. Dazu mĂŒssen sie in AnfĂŒhrungszeichen gesetzt werden. Wenn Sie jedoch eine solche Konstruktion verwenden OnCalendar, vergessen Sie nicht, die AnfĂŒhrungszeichen zu entfernen, da sonst Fehler auftreten: 



[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]#


Lassen Sie uns nun etwas aus der vorherigen Tabelle ĂŒberprĂŒfen. Diese Beschreibung von ihr gefĂ€llt mir besonders gut: 



2022-6,7,8-1,15 01:15:00


Lassen Sie es uns analysieren: 



[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]#


Schauen Mon *-05~3wir uns nun die Beschreibung an , aber dieses Mal werden wir das Programm um Informationen ĂŒber die nĂ€chsten fĂŒnf Male des Timers bitten, der die folgenden Einstellungen verwendet: 



[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 ~]#


Ich glaube, wir haben genug AnwendungsfÀlle behandelt systemd-analyze calendar, damit Sie Ihre eigenen Kalenderereignisbeschreibungen testen können. Beachten Sie, dass das Tool systemd-analyzeweitere interessante Funktionen bietet.



ZusÀtzliche Materialien



Es gibt viele Veröffentlichungen zu systemd im Internet, aber sie sind meistens zu kurz, sehr simpel oder sogar fehlerhaft. Dieser Artikel enthĂ€lt einige gute Informationsquellen zu systemd. Unten finden Sie eine Liste mit Links zu weiteren hochwertigen Materialien zu diesem Thema. 



  • Eine praktische Anleitung zum System des Fedora-Projekts.
  • Ein Spickzettel aus dem Fedora-Projekt, der die alten SystemV- und systemd-Befehle abbildet.
  • Details zu systemd und warum es erstellt wurde.
  • Eine Ressource mit Informationen und RatschlĂ€gen zu systemd.
  • (Lennart Poettering), systemd. , 2010 2011, . systemd .
  • systemd.
  • systemd.




Systemd-Timer können verwendet werden, um dieselben Aufgaben wie Cron-Jobs auszufĂŒhren. Systemd bietet Ihnen jedoch mehr FlexibilitĂ€t bei der Konfiguration von Kalender- und monotonen Timern.



Obwohl die Dienstkonfigurationsdateien, die wir wĂ€hrend unserer Experimente erstellen, normalerweise mit Timern aufgerufen werden, können Sie sie jederzeit mit einem Befehl wie aufrufen systemctl start myMonitor.service. Ein Timer kann mehrere Aufgaben starten. Dies können beispielsweise Bash-Skripte und Linux-Dienstprogramme sein. Eine Dienstkonfigurationsdatei kann so zusammengestellt werden, dass beim Aufruf mehrere Skripts ausgefĂŒhrt werden. Sie können die Skripte auch separat ausfĂŒhren lassen.



Wenn wir ĂŒber die Koexistenz von systemd, cron und at sprechen, möchte ich darauf hinweisen, dass ich noch keine Anzeichen dafĂŒr gesehen habe, dass cron oder at veraltet wĂ€ren. Ich hoffe, dass sie weiterhin unterstĂŒtzt werden, da es zumindest viel einfacher als systemd ist, einmalige Aufgaben zu planen.



Was benutzt du? Systemd Timer oder Cron Jobs?





More articles:


All Articles