Cron vs Systemd计时器


83

最近向我指出,存在cron的替代方法,即systemd计时器。

但是,我对systemd或systemd计时器一无所知。我只用过cron。

Arch Wiki中有一些讨论。但是,我正在寻找cron和systemd计时器之间的详细比较,重点是优点和缺点。我使用Debian,但是我想对所有这两种可用的系统进行一般比较。该集合可能仅包括Linux发行版。

这就是我所知道的。

Cron很老,可以追溯到1970年代后期。cron的原始作者是Unix的创建者Ken Thompson。Vixie cron的历史可以追溯到1987年,其中Vixie cron是现代Linux发行版中的重头戏。

Systemd较新,并且颇有争议。维基百科告诉我它的最初版本是2010年3月30日。

因此,我当前的cron与systemd计时器相比的优点列表是:

  1. 从可安装的受支持软件的意义上讲,Cron被保证可以在任何类Unix系统中使用。那不会改变。相比之下,systemd将来可能会或可能不会保留在Linux发行版中。它主要是一个初始化系统,并且可以由其他初始化系统代替。

  2. Cron易于使用。绝对比systemd计时器简单。

与cron相比,systemd计时器的优点列表如下:

  1. 系统计时器可能更灵活,功能更强大。但我想举个例子。

因此,总而言之,下面是一些可以在答案中看到的东西:

  1. cron计时器与systemd计时器的详细比较,包括使用每个计时器的利弊。
  2. 一个人可以做的事而另一个不能做的事的例子。
  3. cron脚本与systemd timers脚本的至少一个并排比较。

4
“保证Cron可以在任何类似Unix的系统中使用。这不会改变。” –我将对此进行强烈辩论。虽然从历史上看,cron通常被包含在Unix安装的基本设置中,但是在当今的大多数系统上,它只是一个可选的任意可选软件包。实际上,周围有几种流行的cron替代品(例如anacron,fcron,jobber)可能比cron更可取。cron的功能对于系统的操作而言不是systemd或init所必需的,因此,如果您担心当前和将来的可移植性,我宁可不要打赌。
Guido

6
这就是您想要答案中列出的所有内容。我认为,也许您应该花一些时间自己学习工具,看看是否可以自己制定答案,如果您有不了解的特定问题,请在这里询问。
larsks 2016年

5
并不是的。我已经说了关于该主题的所有内容。深入讨论涉及systemd的任何事物总比没有意义要糟糕-有些人认为systemd带来的次要利益值得Linux生态系统的公司垄断。其他人没有。
cas

7
“ Cron很老,可以追溯到1970年代后期。” 实际上是正确的,但是完全不相关,只要以合理且稳定的方式维护系统上的软件包即可。太阳也很老,但是我希望这并不意味着我们应该用更新的东西代替它。
奥西斯

5
@Otheus我认为您认为那部分是错误的-说某件事已经存在很长时间了不是侮辱。至少对许多Unix人士而言。这更像是说一栋房子已有数百年的历史了-这肯定意味着它将有一些问题,一些东西会因翻新而变得怪异,但它也具有一定的魅力,而且它必须被精心建造。这并不是说它的衰败。这是一个简单的工具,已经证明有用了四十年了。
derobert

Answers:


43

以下是有关这两点的几点

  1. 检查您的Cron作业真正完成的工作可能有点混乱,但是所有的systemd计时器事件都会像其他systemd单元一样,根据事件轻松记录在systemd日志中,这使事情变得容易得多。

  2. systemd定时器systemd他们所有的能力资源管理服务,IO CPU调度,......
    有一个列表:

    • 系统调用过滤器
    • 用户/组ID
    • 会员控制
    • 不错的价值
    • OOM分数
    • IO调度类别和优先级
    • CPU调度策略CPU
    • 亲和力umask
    • 计时器松弛
    • 安全位
    • 网络访问和,...
  3. 与其他systemd服务一样,使用dependencies选项可以对激活时间有依赖性。

  4. 可以用不同的方式激活单元,也可以配置它们的组合。可以通过不同的事件(例如用户,引导,硬件状态更改)来启动和触发服务,例如,在某些硬件插入和之后的5分钟内,...

  5. 使用systemd计时器,可以更轻松地配置一些文件和直接标记,以根据您的需要进行各种自定义。

  6. 轻松启用/禁用整个功能:

    systemctl enable/disable 
    

    并用以下方法杀死所有工作的孩子:

    systemctl start/stop
    
  7. 可以使用日历和单调时间来安排systemd计时器,这在不同时区和...的情况下非常有用。

  8. 系统时间事件(日历)比cron更精确(似乎1s精度)

  9. 对于那些重复发生的事件,甚至应该发生一次的事件,systemd时间事件更有意义,这是该文档中的一个示例 :

    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 
    
  10. 从CPU使用率的角度来看,systemd计时器会在经过的时间唤醒CPU,但cron会更频繁地执行此操作。

  11. 可以根据执行的完成时间安排计时器事件,可以在执行之间设置一些延迟。

  12. 与其他程序的通信有时也很值得注意,某些其他程序需要了解计时器及其任务的状态。


2
很好,谢谢。但是,与cron进行更直接的比较将很有帮助,包括一个示例。另外,您编写的某些内容也不是很清楚,例如“从CPU使用率角度来看,systemd计时器会在经过的时间唤醒CPU,但cron会更频繁地执行此操作。”
法赫姆·米莎

你好,@ F.sb!您的答案似乎暗示您可以使用不同的时区安排作业。这个对吗?你会怎么做?与cron的标准实现相比,这将是一个显着的优势,但是我找不到有关它的任何信息,除了man systemd.time似乎与之矛盾的是:不支持UTC以外的非本地时区。
塔德·利斯皮

依赖关系很方便。例如,如果主机备份作为systemd计时器运行,则可以使用依赖项来确保数据库导出在备份之前立即完成。
vk5tu

6
请更诚实一些。您首先要说出这两者的一些要点,然后继续列出您首选的优点。有一个偏好并不坏,但是您应该事先声明。最重要的是,它全都支持一个系统,而没有考虑该系统的优点,这一事实使我感到这个答案是不正确的。
Jasper

2
@jasper亲爱的我根据我的需要使用它们,并且总是根据您的需要选择它们,我只是提到了一些基于文档和手册的事实。
F.sb

16

可以这么说,直接从马口说起:https : //wiki.archlinux.org/index.php/Systemd/Timers#As_a_cron_replacement

上页摘录:

好处

使用计时器的主要好处来自每个作业都有自己的系统服务。其中一些好处是:

  • 可以独立于计时器轻松地启动作业。这简化了调试。
  • 可以将每个作业配置为在特定环境中运行(请参见systemd.exec(5))。
  • 作业可以附加到cgroups。
  • 可以将作业设置为依赖于其他系统单元。
  • 作业记录在systemd日志中,以便于调试。

注意事项

用cron容易完成的某些事情很难单独使用计时器来完成。

  • 复杂性:要使用systemd设置定时作业,您需要创建两个文件并运行几个systemctl命令。相比之下,向crontab中添加一行即可。
  • 电子邮件:没有与cron的MAILTO等效的内置功能,可在工作失败时发送电子邮件。有关使用OnFailure =设置等效项的示例,请参见下一部分。

6
Errr ...不确定我对完全复制和粘贴的答案有何看法,特别是因为许可证不兼容。但是至少,您应该修复“请参阅下一部分”这一位。有了这个错误,就好像您没有阅读所复制粘贴的内容一样。
derobert

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.