我正在将cron作业转换为systemd计时器。 我使用计时器已有几年了，但是通常，我学到的知识足以执行我正在从事的任务。 在研究这个systemd系列产品时 ，我了解到systemd计时器具有一些非常有趣的功能。

像cron作业一样，systemd计时器可以按指定的时间间隔触发事件（shell脚本和程序），例如每天一次，每月的某一天（也许只有星期一）或工作时间内每15分钟触发一次从8am到6pm。 计时器还可以执行cron作业无法执行的某些操作。 例如，计时器可以触发脚本或程序在事件（例如启动，启动，先前任务的完成或什至由计时器调用的服务单元的先前完成）后运行特定时间。

系统维护计时器

在新系统上安装Fedora或任何基于systemd的发行版时，它将创建几个计时器，这些计时器是在任何Linux主机的后台发生的系统维护过程的一部分。 这些计时器触发常见维护任务所需的事件，例如更新系统数据库，清理临时目录，轮换日志文件等。

例如，我将通过使用systemctl status *timer命令列出主机上的所有计时器，来查看主工作站上的一些计时器。 星号符号的作用与文件遍历相同，因此此命令列出了所有systemd计时器单位：

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

• 第一行包含计时器的文件名和其用途的简短说明。
• 第二行显示计时器的状态，是否已加载，计时器单位文件的完整路径以及供应商预设。
• 第三行指示其活动状态，其中包括计时器变为活动状态的日期和时间。
• 第四行包含下一次将触发计时器的日期和时间，以及直到触发发生为止的大概时间。
• 第五行显示计时器触发的事件或服务的名称。
• 一些（但不是全部）systemd单元文件具有指向相关文档的指针。 虚拟机输出中的三个计时器都有指向文档的指针。 这是一个不错的（但可选）数据。
• 最后一行是计时器触发的最新服务实例的日志条目。

根据您的主机，您可能会有一组不同的计时器。

创建一个计时器

尽管我们可以解构一个或多个现有计时器来了解它们的工作原理，但让我们创建自己的服务单元和一个计时器单元来触发它。 为了保持简单，我们将使用一个非常简单的示例。 完成此操作后，您将更容易了解其他计时器的工作原理并确定它们在做什么。

首先，创建一个简单的服务，它将运行一些基本操作，例如free命令。 例如，您可能要定期监视空闲内存。 在/etc/systemd/system目录中创建以下myMonitor.service单元文件。 它不需要是可执行的：

这是关于您可以创建的最简单的服务单元。 现在，让我们看一下状态并测试我们的服务单元，以确保其正常工作。

输出在哪里？ 默认情况下，由systemd服务单元运行的程序的标准输出（ STDOUT ）被发送到systemd日志，这留下了您现在可以稍后查看的记录，直到某个时刻。 （在本系列的后续文章中，我将研究系统化的日记记录和保留策略。）请查看专门针对您的服务部门以及仅适用于今天的日记。 -S选项是--since ，它允许您指定journalctl工具应搜索条目的时间段。 这不是因为您不关心先前的结果-在这种情况下，不会有任何结果-如果您的主机已经运行了很长时间并且积累了大量条目，则可以缩短搜索时间在日记中：

服务触发的任务可以是单个程序，一系列程序或以任何脚本语言编写的脚本。 通过myMonitor.service到myMonitor.service单元文件的[Service]部分的末尾，向该[Service]添加另一个任务：

 ExecStart = / usr / bin / lsblk 

再次启动该服务，并检查日志中的结果，结果应如下所示。 您应该在日志中看到两个命令的结果：

既然您知道您的服务将按预期工作， myMonitor.timer在/etc/systemd/system创建计时器单元文件myMonitor.timer ，并添加以下内容：

myMonitor.timer file *-*-* *:*:00的OnCalendar时间规范应触发计时器，每分钟执行一次myMonitor.service单元。 我将在本文的后面部分探讨OnCalendar设置。

现在，观察由计时器触发的与运行服务有关的所有日记帐分录。 您也可以遵循计时器，但是遵循服务可以使您几乎实时地查看结果。 使用-f （follow）选项运行journalctl ：

启动，但不启用计时器，看看它运行一段时间后会发生什么：

一个结果立即显示出来，而下一个结果则以一分钟的间隔出现。 观看日志几分钟，看看您是否注意到我做的同样的事情：

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

来自ExecStart STDOUT触发器将存储在myMonitor.service单元中的日记中。 这就是使用systemd运行服务的全部部分。 但是，这确实意味着您可能需要注意从服务单元运行脚本以及它们生成多少STDOUT 。

第二件事是计时器不会在：00秒的分钟或从前一实例开始的精确一分钟触发。 这是有意的，但是可以在必要时覆盖它（或者如果它只是冒犯了sysadmin敏感性）。

此行为的原因是为了防止多个服务完全同时触发。 例如，您可以使用时间规格，例如每周，每天等等。 这些快捷方式均已定义为在触发当天的00:00:00小时触发。 当以此方式指定多个计时器时，它们很可能会尝试同时启动。

systemd计时器经过专门设计，可以在指定时间左右随机触发，以防止同时触发。 它们在时间窗口内半随机触发，该时间窗口从指定的触发时间开始，到指定的时间加一分钟结束。 根据systemd.timer手册页，此触发时间相对于所有其他定义的计时器单元保持在稳定的位置。 您可以在上面的日记条目中看到，计时器在启动时立即触发，然后在每分钟大约46或47秒后触发。

在大多数情况下，这种概率触发时间很好。 安排诸如备份之类的任务运行时，只要它们在下班时间运行，就不会有问题。 系统管理员可以选择确定性的开始时间，例如典型的cron作业规范中的01:05:00，以不与其他任务冲突，但是可以通过很大的时间值来完成。 开始时间中一分钟的随机性通常是无关紧要的。

但是，对于某些任务，绝对的触发时间是绝对必要的。 对于这些，您可以通过将以下语句添加到计时器单位文件的“ Timer部分中来指定更高的触发时间跨度精度（以微秒为单位）：

 AccuracySec =1us 

时间跨度可用于指定所需的精度，以及定义重复事件或一次性事件的时间跨度。 它可以识别以下单位：

• usc，我们，微秒
• 毫秒，毫秒
• 秒，秒，秒
• 分钟，分钟，分钟，米
• 小时，小时，小时，小时
• 天，天，d
• 周，周，周
• 月，月，M（定义为30.44天）
• 年，年，y（定义为365.25天）

/usr/lib/systemd/system所有默认计时器都为精度指定了更大的范围，因为精确时间并不重要。 查看系统创建的计时器中的一些规范：

在/usr/lib/systemd/system目录中查看某些计时器单元文件的完整内容，以了解它们的构造方式。

您不必启用此实验中的计时器即可在启动时将其激活，但是执行该命令的命令将是：

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

您创建的单元文件不需要可执行。 您还没有启用服务单元，因为它是由计时器触发的。 如果需要，您仍然可以从命令行手动触发服务单元。 试试看，观察日志。

有关计时器精度，事件时间规格和触发事件的更多信息，请参见systemd.timer和systemd.time的手册页。

计时器类型

systemd计时器具有cron所没有的其他功能，仅在特定，重复，实时的日期和时间触发。 可以将systemd计时器配置为基于其他systemd单元中的状态变化进行触发。 例如，可以将计时器配置为在系统引导之后，启动之后或激活定义的服务单元之后触发特定的经过时间。 这些称为单调计时器。 单调是指连续增加的计数或序列。 这些计时器不是持久性的，因为它们在每次引导后都会重置。

表1列出了单调计时器以及每个计时器的简短定义以及OnCalendar计时器，该计时器不是单调的，用于指定将来的时间，该时间可能重复也可能不重复。 此信息是从systemd.timer手册页派生而来，但systemd.timer了一些小的更改。

计时器	单调的	定义
OnActiveSec=	X	这相对于计时器被激活的时刻定义了一个计时器。
OnBootSec=	X	这定义了相对于机器启动的计时器。
OnStartupSec=	X	这定义了相对于服务管理器首次启动的计时器。 对于系统计时器单元，这与OnBootSec=非常相似，因为系统服务管理器通常在启动时就很早启动。 当以在每个用户服务管理器中运行的单元进行配置时，它尤其有用，因为用户服务管理器通常仅在首次登录时启动，而不是在启动过程中启动。
OnUnitActiveSec=	X	这定义了相对于上一次要激活的计时器的激活时间的计时器。
OnUnitInactiveSec=	X	相对于上一次要激活的计时器的时间，它定义了一个计时器。
OnCalendar=		这使用日历事件表达式定义了实时（即挂钟）计时器。 有关日历事件表达式的语法的更多信息，请参见systemd.time(7) 。 否则，语义类似于OnActiveSec=和相关设置。 此计时器与cron服务最相似。

表1：systemd计时器定义

单调计时器的时间跨度可以使用与前面提到的AccuracySec语句相同的快捷方式名称，但是systemd会将这些名称标准化为秒。 例如，您可能想指定一个计时器，该计时器在系统启动五天后一次触发一次事件； 可能看起来像： OnBootSec=5d 。 如果主机在2020-06-15 09:45:27引导，则计时器将在2020-06-20 09:45:27或之后的一分钟内触发。

日历活动规范

日历事件规范是在所需的重复时间触发计时器的关键部分。 首先查看与OnCalendar设置一起使用的一些规格。

与crontab中使用的格式相比，systemd及其计时器使用的时间和日期规范风格不同。 它比crontab更加灵活，并且可以按at命令的方式允许模糊的日期和时间。 还应该足够熟悉，以使其易于理解。

使用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	与每周相同
Mon	与每周相同
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
Mon *-05~03	每年的5月的下一个星期一发生，这也是该月末的第3天。
Mon..Fri *-08~04	任何年份的8月底前的第4天，也属于工作日。
*-05~03/2	从5月底开始的第3天，然后再过两天。 每年重复一次。 请注意，此表达式使用波浪号（〜）。
*-05-03/2	5月的第三天，然后是5月其余的第二天。 每年重复一次。 请注意，此表达式使用破折号（-）。

表2：示例OnCalendar事件规范

测试日历规格

systemd提供了一个出色的工具，可用于验证和检查计时器中的日历时间事件规范。 systemd-analyze calendar工具解析日历时间事件规范，并提供规范化形式以及其他有趣的信息，例如下一个“经过”（即匹配）的日期和时间以及触发时间之前的大概时间到达了。

首先，查看没有时间的未来日期（请注意， Next elapse和UTC将根据您所在的时区而有所不同）：

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

要将日期和时间作为一个整体进行分析，请将其用引号引起来。 在计时器单元的OnCalendar=事件规范中使用引号时，请确保将其删除，否则会出现错误：

现在测试表2中的条目。我喜欢最后一个，尤其是：

让我们看一个示例，其中列出时间戳表达式的下五个经过时间。

这应该为您提供足够的信息来开始测试OnCalendar时间规格。 systemd-analyze工具可用于其他有趣的分析，我将在本系列的下一篇文章中开始探讨。

摘要

可以使用systemd计时器执行与cron工具相同的任务，但是在日历和单调时间规范方面可以提供更大的灵活性来触发事件。

即使您为此实验创建的服务单元通常是由计时器触发的，您也可以随时使用systemctl start myMonitor.service命令来触发它。 可以在单个计时器中编写多个维护任务的脚本； 这些可以是Bash脚本或Linux实用程序。 您可以运行由计时器触发的服务以运行所有脚本，也可以根据需要运行单个脚本。

在下一篇文章中，我将详细探讨systemd对时间和时间规范的使用。

我尚未看到cron和at将被弃用的任何迹象。 我希望不会发生，因为at ，至少是使用更容易为一次性任务调度比systemd定时器。

资源资源

互联网上有大量有关systemd的信息，但是很多信息简洁，晦涩甚至是误导。 除了本文提到的资源之外，以下网页还提供了有关systemd启动的更详细和可靠的信息。

• Fedora项目对systemd有很好的实用指南 。 它具有使用systemd配置，管理和维护Fedora计算机所需的几乎所有知识。
• Fedora项目还有一个很好的备忘单 ，可以将旧的SystemV命令与可比的systemd命令进行交叉引用。
• 有关systemd及其创建原因的详细技术信息，请查看Freedesktop.org 对systemd的描述 。
• Linux.com的“更多系统乐趣”提供了更多高级系统信息和技巧 。

还有systemd的设计师和主要开发者Lennart Poettering撰写的一系列针对Linux sysadmin的技术性文章。 这些文章是在2010年4月至2011年9月之间撰写的，但它们现在和那时一样具有相关性。 关于systemd及其生态系统的许多其他优点都基于这些论文。

• 重新思考PID 1
• 系统管理员，第一部分
• 系统管理员，第二部分
• 系统管理员，第三部分
• 管理员专用的systemd，第IV部分
• 系统管理员，第五部分
• 管理员专用的systemd，第VI部分
• 管理员专用系统，第七部分
• 管理员专用的系统化第八部分
• 管理员专用的systemd，第IX部分
• 适用于管理员的systemd，第X部分
• 管理员专用系统，第十一部分

翻译自: https://opensource.com/article/20/7/systemd-timers