但是，我对systemd或systemd计时器一无所知。我只用过cron。
Arch Wiki中有一些讨论。但是，我正在寻找
cron和systemd计时器之间的详细比较，重点是优点和缺点。我使用Debian，但我希望对所有这两种替代方法都可用的系统进行一般比较。这套软件可能只包括Linux发行版。这就是我所知道的。
Cron很老，可以追溯到1970年代后期。 cron的原始作者是Unix的创建者Ken Thompson。 Vixie cron可以追溯到1987年。Vixiecron可以追溯到1987年。现代Linux发行版中的重头戏是直接后代。
Systemd较新，并且存在一定争议。 Wikipedia告诉我它的最初发布日期是2010年3月30日。
所以，我目前的cron优于systemd计时器的优点是：
Cron一定会在任何类似Unix的系统中，从某种意义上讲，它是一种可安装的受支持软件。那不会改变
。相反，将来systemd可能会保留在Linux
发行版中，也可能不会保留。它主要是一个初始化系统，并且可以
替换为其他初始化系统。
Cron使用简单。绝对比systemd计时器简单。
systemd计时器相对于cron的优点是：
Systemd计时器可能更灵活，功能更强大。但是我想要
示例。
因此，总而言之，以下是一些可以在答案中看到的东西：
对cron计时器和systemd计时器的详细比较，包括优点和使用它们的缺点。
一个例子可以做到而另一个则不能。
至少一个并排cron脚本与systemd计时器脚本的比较。
#1 楼
以下是关于这两个方面的一些要点：检查您的cron作业的实际执行情况可能有点混乱，但是
所有systemd计时器事件都已仔细记录在systemd日志中
像其他基于事件的systemd单元一样，它使事情变得更容易。
systemd计时器是systemd服务，具有所有功能，可用于资源管理，IO CPU调度，...
有一个列表：
系统调用筛选器
用户/组IDs
membershipcontrols
/>好值
OOM分数
IO调度类和优先级
CPU调度策略CPU
定时器松弛
安全位
网络访问和，...
与其他系统服务一样，使用依赖性选项
也可以依赖于激活时间。
可以用不同的方式激活单元，还可以配置它们的组合。服务可以通过不同的事件（例如用户，引导，硬件状态更改）启动或触发，或者例如在插入某些硬件并在5分钟后进行
示例，...更容易配置一些文件并直接进行标签
使用systemd
定时器根据您的需求进行各种自定义。
通过以下功能轻松启用/禁用整个功能：
systemctl enable/disable
，并使用以下方法杀死所有工作的孩子：
systemctl start/stop
可以使用压光机和单调时间安排系统计时器
，在时区不同的情况下很有用，并且...
系统时间事件（日历）比cron（似乎
1s精度）更准确
系统时间事件对于那些经常发生的事件甚至更应该发生一次的事件，它们更有意义，这是
文档中的示例：
Sat,Thu,Mon-Wed,Sat-Sun → Mon-Thu,Sat,Sun *-*-*00:00:00
Mon,Sun 12-*-* 2,1:23 → Mon,Sun 2012-*-* 01,02:23:00
Wed *-1 → Wed *-*-01 00:00:00
Wed-Wed,Wed *-1 → Wed *-*-01 00:00:00
Wed, 17:48 → Wed *-*-* 17:48:00
从CPU使用率观点systemd计时器在
上唤醒CPU已耗用时间，但cron经常这样做。
可以根据执行的完成时间安排计时器事件。在执行之间可以设置一些延迟。
有时与其他程序的通信也很明显
其他一些程序需要了解计时器及其任务的状态。
评论
很好，谢谢。但是，与cron进行更直接的比较将很有帮助，包括一个示例。另外，您写的某些内容也不是很清楚，例如“从CPU使用率的角度来看，systemd计时器会在经过的时间唤醒CPU，但cron更经常这样做。”
– Faheem Mitha
16年5月5日在8:49
你好@ F.sb！您的答案似乎暗示您可以使用不同的时区安排作业。这个对吗？你会怎么做？与cron的标准实现相比，这将是一个显着的优势，但是我找不到任何有关它的信息，除了man systemd.time似乎与之矛盾的是：不支持UTC以外的非本地时区。
–塔德·利斯皮（Tad Lispy）
17年5月24日在15:48
依赖关系很方便。例如，如果主机备份作为systemd计时器运行，则可以使用依赖项来确保数据库导出在备份之前立即完成。
–vk5tu
17年11月22日在11:17
@jasper亲爱的我根据自己的需要使用它们，并且总是根据您的需要选择它们，我只是提到了一些基于文档和手册的事实。
– FargolK
17年12月6日在9:30
#2 楼
可以这么说：从马的嘴巴直接出来：https：//wiki.archlinux.org/index.php/Systemd/Timers#As_a_cron_replacement上一页的摘录： />
好处
使用计时器的主要好处来自每个作业都有自己的系统服务。其中的一些好处是：
作业可以独立于计时器轻松启动。这简化了调试。
可以将每个作业配置为在特定环境中运行（请参见systemd.exec（5））。
作业可以附加到cgroups。
作业可以设置为依赖于其他系统单元。
作业记录在系统日志中，以便于调试。
注意事项
用cron容易完成的一些事情很难做到
复杂性：要使用systemd设置定时作业，您需要创建两个文件并运行几个systemctl命令。相比之下，向crontab中添加一行即可。
电子邮件：没有与cron的MAILTO等效的内置功能，可用于在作业失败时发送电子邮件。有关使用OnFailure =设置等效项的示例，请参见下一部分。
评论
Errr ...不确定我对完全复制和粘贴的答案有何看法，特别是因为许可证不兼容。但是至少，您应该修复“请参阅下一部分”这一位。有了这个错误，就好像您没有阅读所复制粘贴的内容一样。
–德罗伯特
17年1月4日在23:17
当您从某处引用材料时，必须引用来源，并且必须明确指出所引用的内容。窃并不酷。
–吉尔斯'所以-不再是邪恶的'
17年1月4日在23:22
评论
“保证Cron可以在任何类似Unix的系统中使用。这不会改变。” –我将对此进行强烈辩论。尽管从历史上看，cron通常被包含在Unix安装的基本设置中，但是在当今大多数系统上，它只是一个可选的任意可选软件包。实际上，周围有几种流行的cron替代品（例如anacron，fcron，jobber）可能比cron更可取。 cron的功能对于系统的操作而言并不是systemd或init所必需的，因此，如果您担心当前和将来的可移植性，我宁可不要打赌。这就是您想要答案中列出的所有内容。我认为，也许您应该花一些时间自己学习工具，看看是否可以自己制定答案，如果您有不明白的特定问题，请在这里询问。
并不是的。我已经说了关于该主题的所有内容。深入讨论涉及systemd的事物总比没有意义要糟-有些人认为systemd带来的次要利益值得Linux生态系统的公司垄断。其他人没有。
“ Cron很老，可以追溯到1970年代后期。”实际上是正确的，但完全不相关，只要以合理且稳定的方式维护系统上的软件包即可。太阳也很老，但是我希望这并不意味着我们应该用更新的东西代替它。
@Otheus我认为您认为那部分是错误的-说某件事已经存在很长时间了不是侮辱。至少对许多Unix人士而言。这更像是说一栋房子已有数百年的历史了–这肯定意味着它将有一些问题，一些东西因翻新而变得很奇怪，但它也具有一定的魅力，并且必须建造良好。这并不是说它的衰败。这是一个简单的工具，已经证明有用了四十年了。