☰

时区更改后 Cron 作业不会启动

tag-icon • tag-icon cron timezone
时区更改后 Cron 作业不会启动

我尝试过消除许多常见错误，

  1. 确保 PATH 可用于 cron

  2. crontab 文件末尾有一个结束行

  3. 时区的设置方式为：

    cd /etc
cp /usr/share/zoneinfo/Asia/Singapore /etc/localtime

在 bash 中运行date，我得到：

Tue Sep 17 15:14:30 SGT 2013

为了检查 cron 是否使用相同的时间，

* * * * * date >> date.txt

在 date.txt 中给出相同的日期输出。

这是我试图执行的脚本：

event.sh:

#!/usr/bin/env bash
echo data > /root/data.txt

使用crontab -e，下面的行有效，

* * * * * /bin/bash /root/event.sh >/tmp/debug.log 2>&1

15 * * * * /bin/bash /root/event.sh >/tmp/debug.log 2>&1

然而，当我尝试其他一些参数时，希望它能在下午 2.50 运行：

50 14 * * * /bin/bash /root/event.sh >/tmp/debug.log 2>&1

或者

50 14 * * * (cd /root ; ./event.sh >/tmp/debug.log 2>&1)

它将不再起作用。看来我的时间论点有问题。文件中也找不到任何内容/tmp/debug.log。

解决方案：

结果我必须在对 TZ 进行更改后重新启动 cron 服务。

答案1

首先，您遇到导致错误考虑一个字段的错误的可能性似乎是异常地低的。这更有可能是对正在发生的事情和 cron 期望的误解。

在这种情况下，我们在问题的评论中发现这很可能是与时区相关的问题。为此，您会：

  • 添加一个类似于* * * * * datecrontab 的条目
  • 消除（或注释掉）来自 crontab 的任何 TZ 分配

这会强制date使用调用者的时区设置运行，这意味着 cron 守护进程。查看输出；它将显示 cron 在内部使用的时区，因此很可能希望其时间字段位于哪个时区。如果您在 crontab 中有 TZ 分配，则 TZ 环境变量分配很容易传递到调用的命令但 cron 本身使用其他时区。通过注释或删除 TZ 分配，可以避免这种歧义。

还要注意，对系统全局时区设置的任何更改（包括例如 /etc/localtime）几乎肯定需要至少重新启动 cron 守护程序，并且可能（尽管不太可能）需要重新启动系统才能完全生效。在 crontab 中编辑 TZ 分配不应该需要重新加载 cron 守护进程，因为它应该检测到文件已更改并自动重新加载。

相关内容