☰

crontab 的无效时间检查不一致

tag-icon • tag-icon cron
crontab 的无效时间检查不一致

我们的一位 DBA 创建了以下 crontab 条目，以便每天从早上 6:30 到午夜每 3 小时运行一次备份：

30 6-24/3 * * * (path to backup script)

Cron 记录了该条目，但并未按预期运行备份。我既不是系统管理员也不是 Linux 专家。我的分析是，该条目应该是（因为小时永远不会等于 24）：

30 6-23/3 * * * (path to backup script)
  1. 哪个条目是正确的？如果第一个条目是错误的，为什么 crontab 允许 DBA 创建该条目？它应该抛出一个错误。
  2. 如果我想创建一个条目，从早上 6:30 到晚上 11:30 每 3 小时运行一次备份，我该如何创建 crontab 条目？没有示例显示以半小时结束的时间范围。

编辑：系统是Oracle Enterprise Linux 5。

该脚本在 23:00 之前仅运行过一次。我会进行更多测试并回复。我仍然不明白 cron 如何接受非法小时值 (24)。

这很奇怪。如果我创建一个如下条目：

30 6-24/3 * * * /bin/ls

我无法保存 crontab。我收到错误，说时间不对。如果我创建如下条目：

30 6-24/4 * * * /bin/ls

我可以保存该条目。它没有意义。该小时仍然很糟糕，但被接受了。这是一个错误还是预期的行为？

MadHatter：请随意更改帖子标题并提交错误。正如我所说，我不是 Linux 专家，只是同事们讨论技术问题的人。我真的很喜欢这个网站。贡献者知识渊博，乐于助人。

谢谢，阿伦

答案1

这显然是一个错误，它似乎影响了多种版本的 Red Hat 系统。我已经在 CentOS 5、C6、Fedora 19 和 Fedora 20 上确认了您描述的行为。

对于crontab表单的条目

30 a-b/c * * *  /bin/ls

看起来如果如果不存在正整数 n，并且a+nc位于 范围内[24,b]，则最后一个小时 ( b) 的无效性检查无效。也就是说，您可以编写胡言乱语，只要操作系统实际上不必对此做任何事情；如果您指定范围和间距，以至于它实际上会在无效时间（包括24）触发作业，则会crontab出现投诉。

我刚刚说服我的 F20 系统接受该crontab条目

30 6-33/16 * * *  /bin/ls

按照任何标准来看，这都是疯狂的。同样，30 2-33/14 * * * /bin/ls和30 1-33/16 * * * /bin/ls都给出了（期望的）bad hour错误，而30 2-27/14 * * * /bin/ls有效。

恭喜你，阿伦，我想你找到了一个善意Red Hat 中的错误crontab（它不是Ubuntu 12.04LTS 上存在此问题，尽管这是我手头上唯一可以测试的其他系统）。您是否要使用 RH bugzilla 记录它，还是我应该记录？

答案2

将 24 替换为0(即 24)，至于第二项，最后一项工作将在 21:30 运行。

你也可以尝试这个：

30 0,6,9,12,15,18,21 * * * /path/to/script

完整语法：

# cat /etc/crontab 
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed

#

相关内容