Clever Geek Handbook

使用systemd计时器而不是cron作业

我目前正在用systemd计时器替换我的cron作业。我已经使用计时器好几年了，但是通常我不会深入了解它们的用法，只了解完成我感兴趣的任务所需的条件。我最近在systemd上撰写了一系列文章，发现systemd计时器具有一些非常有趣的功能。







这些计时器（例如cron作业）可以在给定的时间触发系统上的各种操作。例如-运行Shell脚本或程序。计时器可以每天工作一次，例如仅星期一。另一个示例是一个计时器，该计时器在工作时间（从上午8点到下午6点）每15分钟触发一次。但是systemd计时器可以执行cron作业无法执行的操作。例如，计时器可以在事件发生后的指定时间调用脚本或程序。这样的事件可以是系统引导或systemd启动，先前任务的完成，甚至是计时器之前调用的服务的终止。



用于系统维护的计时器



在计算机上安装Fedora或其他基于systemd的Linux发行版时，会创建多个计时器作为系统维护例程的一部分。这些过程可在任何Linux系统上自动执行。相应的计时器会触发各种服务任务，例如更新系统数据库，清除临时目录，轮换日志文件等等。



例如，我将在此处提供有关我用于实验的虚拟机上可用的计时器的信息。在这里，要获取所有计时器的列表，我使用了以下命令systemctl status *timer... 星号通配符在这里的作用与其他类似命令中的作用相同。即，它告诉系统我们对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.


每个计时器至少与包含有关其信息的六行相关联：



  • 第一行包含计时器文件的名称和计时器存在目的的简短描述。
  • 第二行显示有关计时器状态的信息。即，它报告它是否已加载，给出计时器文件的完整路径，显示供应商预设的状态（禁用或启用）。
  • 第三行显示有关计时器活动的信息，其中包括有关计时器激活时间的信息。
  • 第四行包含计时器下一次启动的日期和时间以及开始计时之前的剩余时间。
  • 第五行给出了计时器调用的服务或事件的名称。
  • 一些（但不是全部）systemd计时器单元文件包含指向文档的指针。在我的示例中，此类指针位于三个计时器的描述中。
  • 计时器说明中的最后一行是与计时器调用的服务的最新实例相关联的日志条目。


如果您尝试在计算机上执行命令systemctl status *timer，则显示给它的计时器可能与我的不同。



计时器创建



尽管我们可以通过分析任何现有的计时器来弄清楚计时器的工作原理，但我建议创建自己的服务单元文件（服务配置文件，service unit）和一个计时器文件，使用该文件将调用相应的服务。为了不使故事复杂化，我们在这里举一个简单的例子。但是，在我们处理之后，您将更容易理解其他计时器的工作。



首先，让我们创建一个简单的服务配置文件，该文件将运行像command一样简单的东西free。例如，如果我们需要定期监视可用内存量，则可能需要这样做。让我们myMonitor.service在文件夹中创建一个单位文件/etc/systemd/system。它不必是可执行的。 



# 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


该文件可能是最简单的服务配置文件。现在，让我们检查其状态并对其进行测试，以确保其可以正常工作。 



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


为什么没有任何输出到控制台？这是因为，默认情况下，stdoutsystemd使用服务单元文件启动的程序的标准输出（）被重定向到systemd日志。因此，至少只要存在相应的记录，就可以分析这些记录。让我们在日志中查找与我们的服务和测试日期相关的条目。相应的命令将如下所示: journalctl -S today -u myMonitor.service。密钥-S是缩写版本--since。它允许您指定实用程序的时间段journalctl寻找记录。关键不是我们对早期结果不感兴趣。在我们的情况下，这样的结果根本不会。此键用于减少实用程序搜索数据所需的时间。如果计算机已经工作了很长时间，则日志中会积累很多条目。 



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


使用服务配置文件启动的任务可以表示为单个程序，程序序列或以任何脚本语言编写的脚本。让我们向单元文件添加myMonitor.service另一个任务，在本节末尾包括[Service]以下内容： 



ExecStart=/usr/bin/lsblk


让我们再次启动该服务并检查日志。里面应该有类似下面显示的内容。即，日志应包含两个命令输出的数据： 



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.


现在，在确定一切正常后，我们将在该文件夹中创建/etc/systemd/system一个计时器单位文件，并为其命名myMonitor.timer。将以下内容添加到文件中： 



# 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文件中的时间戳*-*-* *:*:00应使计时器myMonitor.service每分钟调用一次设备。OnCalendar我们将在下面详细讨论。



同时，我们可以看一下与启动计时器服务有关的日志条目。我们还可以打开计时器监视模式。但是，监视服务将使您几乎实时地看到结果。为此，您需要journalctl使用键-f（follow）运行： 



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


启动计时器，但不要在系统启动时将其包括在自动启动中。  



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


观察一段时间会发生什么。



结果之一立即出现。下一个将以大约一分钟的间隔显示。观看杂志几分钟。 



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


确保同时检查计时器状态和服务状态。



您是否在这里注意到我所注意到的？阅读杂志时，您可能已经注意到至少两件事。



首先-事实是您不需要ExecStart为myMonitor.service写入日志记录做特别的事情stdout。此功能是标准systemd启动功能的一部分。但这意味着从服务配置文件运行脚本时，您可能需要小心，注意它们写入了多少数据stdout。



其次，您可能已经注意到计时器未完全在以下时间开始:00每分钟的秒数，甚​​至不是最后一次运行后的一分钟。这是此类计时器的功能之一，如果有必要（或者如果它会损害系统管理员的感觉），可以通过使计时器更精确来更改其行为。



计时器无法在:00每分钟的几秒钟内启动的原因是因为系统倾向于防止同时启动多个服务。例如，在设置时间指示器时，OnCalendar您可以使用Weekly，Daily和其他值。设置了这些简短的命名时间方式，以便使用它们的计时器从00:00:00相应的日期。当以此方式配置多个计时器时，它们将同时触发的可能性很高。



这就是为什么有系统地设计计时器的原因，以便它们不会在指定的时间准确启动，而是有一些随机偏差。这种偏差不能被称为完全偶然的。计时器从时间窗口的某个地方开始，该时间窗口从指定的时间开始，到原始时间的一分钟结束。systemd.timer考虑到系统中声明的所有其他计时器，根据的文档，此时间保持稳定状态。在上面的日志片段中，您可以看到计时器在启动后立即触发，然后-每隔一分钟开始后大约46或47秒触发一次。



通常，这种确定计时器准确计时的概率方法适合每个人。在安排工作时间（例如在工作时间以外执行某事的备份副本）时，这不是问题。设置cron作业的系统管理员可以指定明确定义的启动时间，例如01:05:00尝试确保这些作业不会与其他作业冲突。有各种各样的方法可以指定时间。任务开始时间的随机变化（不超过一分钟）通常不会发挥特殊作用。



但是对于某些任务，计时器的准确计时极为重要。在这种情况下，设置计时器时，您可以指定更精确的操作时间（精度最高，以微秒为单位）。这是通过在部分的计时器描述文件中添加Timer类似于以下内容的构造来完成的： 



AccuracySec=1us


您可以使用特殊关键字来指定所需的计时器精度。在设置定期事件和一次性事件时，也可以使用这些关键字。系统了解以下关键字：



  • 微秒级：usec，us，µs。
  • 毫秒：msec，ms。
  • 二：seconds，second，sec，s。
  • 分钟：minutes，minute，min，m。
  • 小时：hours，hour，hr，h。
  • 日：days，day，d。
  • 周：weeks，week，w。
  • 月：months，month，M（每月被定义为30.44天）。
  • 年份：years，year，y（今年被定义为365.25天）。


所有可用的标准计时器都/usr/lib/systemd/system使用更长的范围来配置，以设定其触发精度，因为在这些计时器的情况下，在严格指定的时间触发并不特别重要。看一下一些系统生成的计时器的规格： 



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


为了从目录更好地了解计时器文件的内部结构/usr/lib/systemd/system，可以查看其内容。



您无需将我们的学习计时器配置为在系统启动时激活。但是，如果需要，可以为此使用以下命令： 



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


您将创建的计时器文件不需要是可执行文件。另外，服务配置文件不需要配置为在启动时激活，因为它们由计时器调用。如有必要，还可以从命令行手动调用该服务。尝试此操作并查看systemd日志。



要了解更多关于定时器，如何确定事件的时间触发的准确性，以及如何触发事件，请参阅文件systemd.timer和systemd.time。



计时器类型



系统计时器具有cron作业不具备的其他功能（一次性或重复性），这些功能只能通过实时日期和实时日期来调用。可以将Systemd定时器配置为基于其他Systemd单元的状态变化进行调用。例如，可以配置一个计时器，使其在系统启动后的指定时间之后，用户登录后或激活某种服务后的指定时间之后被触发。这些计时器称为单调计时器。每次系统重新引导后，这些计时器都会重置。



下表显示了单调计时器的列表，并简要说明了每个计时器。也有计时器的说明。OnCalendar，它不是单调的，用于将来需要组织一次或多次发布的事情。该表基于文档systemd.timer。

计时器 单调 描述 
OnActiveSec=


X 定时器操作时间是相对于定时器激活时刻而设置的。 
OnBootSec=


X 计时器是相对于系统启动的时间设置的。 
OnStartupSec=


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


X , , , . 
OnUnitInactiveSec=


X , , , . 
OnCalendar=


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


设置单调计时器时，可以像上面讨论的那样使用相同的关键字AccuracySec。但应注意，systemd将相应的时间间隔转换为秒。例如，您可能想要设置一个计时器，该计时器在系统启动五天后触发一次。可能看起来像这样的描述：OnBootSec=5d。如果计算机是在引导2020-06-15的09:45:27，则计时器将2020-06-20在09:45:27（或在该时间点后1分钟内）启动。



日历活动的描述



应用日历事件是描述定期调用计时器的关键部分。让我们检查设置时间指示器时使用的此类事件的某些功能OnCalendar。



Systemd及其对应的计时器使用与crontab不同的时间和日期格式。这种格式比crontab中使用的格式更灵活。它允许您以命令方式以简化的方式指定日期和时间at。对于熟悉它的人来说at，应该很容易理解systemd计时器设置。



当用于OnCalendar=设置计时器时，以下基本格式用于指定日期和时间： 



DOW YYYY-MM-DD HH:MM:SS


DOW（星期几）是上述构造的可选部分。在其他字段中，您可以使用星号（*）符号表示可能出现在其位置上的任何值。日期和时间指示的所有形式都将转换为规范化形式。如果未指定时间，则假定为00:00:00。如果未指定日期，但指定了时间，则计时器将在开始日期（相对而言，“今天”）或第二天（“明天”）工作。这取决于当前时间。可以使用它们的名称来命名一周中的月份和日期。您可以在此处使用逗号分隔的值列表。值的范围可以在范围…的开始和结束值之间用三个点（）分隔。



在指定日期时，我们有几个有趣的选项可供您使用。因此，代字号（〜）可用于指示一个月的最后一天，或指示一个月中最后一天之前给定天数的日期。正斜杠（/）可用作修饰符，以指示星期几。



下表显示了表达式中使用的时序的一些典型示例OnCalendar。



演示日历事件的示例 DOW YYYY-MM-DD HH:MM:SS

描述 
*-*-* 00:15:30


每年每个月的每天，午夜15分30秒。 
Weekly


每周一的星期一00:00:00。 
Mon *-*-* 00:00:00


与相同Weekly。 
Mon


与相同Weekly。 
Wed 2020-*-*


2020年每个星期三在00:00:00。 
Mon..Fri 2021-*-*


2021年的每个工作日在00:00:00。 
2022-6,7,8-1,15 01:15:00


2022年6月1日和15日，01:15:00午夜后的7月和8月。 
Mon *-05~03


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


, 4 , . 
*-05~03/2


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


, — . . , (-).


,



Systemd有一个很棒的工具可以检查和检查日历事件规范。我们正在谈论的是一个团队systemd-analyze calendar，该团队解析日历事件的描述并以规范化形式显示它们。此命令还提供其他有趣的信息，例如下一个此类事件的日期和时间，以及到该时刻为止的剩余大概时间。



首先，让我们看一下该规范，该规范仅包含日期，不包含有关时间的信息（请注意，字段中的时间不同，Next elapse并且(in UTC)这些时间取决于本地时区）： 



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


现在，将时间信息添加到描述中。在此示例中，将日期和时间作为互不相关的实体分别进行分析： 



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


现在考虑一个将日期和时间一起考虑的示例。为此，必须将它们用引号引起来。但是，如果您在中使用了这样的构造OnCalendar，请不要忘记删除引号，否则您将面临错误： 



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


现在，让我们检查上表中的内容。我特别喜欢她的描述： 



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


让我们来分析一下： 



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


现在让我们看一下说明Mon *-05~3，但是这次我们将向程序询问有关接下来5次计时器的信息，该计时器使用以下设置： 



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


我相信我们已经介绍了足够的用例systemd-analyze calendar，可以帮助您开始测试自己的日历事件定义。请记住，该工具systemd-analyze还有其他有趣的功能。



附加材料



互联网上有许多systemd上的出版物，但是它们大多太短，太简单了，甚至有故障。本文提供了一些有关systemd的信息。以下是有关此主题的一些高质量材料的链接列表。 



  • Fedora项目的实用指南。
  • Fedora项目的备忘单，用于映射旧版SystemV和systemd命令。
  • 有关systemd及其创建原因的详细信息。
  • 包含信息和建议的材料，专用于systemd。
  • (Lennart Poettering), systemd. , 2010 2011, . systemd .
  • systemd.
  • systemd.




可以使用Systemd计时器完成与cron作业相同的任务。但是systemd在配置日历和单调计时器方面为您提供了更大的灵活性。



尽管我们通常在实验过程中创建的服务配置文件通常是使用计时器调用的，但您仍可以随时使用像这样的命令来调用它们systemctl start myMonitor.service。一个计时器可以启动多个任务。例如，这可以是Bash脚本和Linux实用程序。可以组成服务配置文件，以便在调用该服务配置文件时执行多个脚本。您还可以使脚本单独运行。



如果我们谈论systemd，cron和at的并存，那么我想指出的是，我还没有看到cron或at被淘汰的迹象。我希望他们将继续得到支持，因为至少比systemd更容易安排一次任务。



你在用什么 系统计时器或cron作业？





More articles:


All Articles