Linux Crontab 时区之谜：为何运行时间与预设时间相差8小时

环境：Oracle Linux
现象：crontab 配置凌晨 0:30 执行，实际却在上午 8:30 运行
根因：crond 守护进程启动时缓存了时区，系统时区后续变更后，crond 仍沿用旧缓存
核心教训：date 命令看到的时区 ≠ crond 调度使用的时区

---

一、问题现象

某天检查定时任务日志时，发现了一个诡异的现象：

# crontab 配置
30 0 * * * xxxxxxxx.sh >xxxxx.log

配置的是每天 凌晨 0:30 执行脚本，但 /var/log/cron 中的实际执行记录却是8:30，

整整偏移了 8 小时！

---

二、排查过程：那些差点让我走弯路的方向

方向 1：怀疑系统时区配置有问题

看到8小时，作为东八区的大家，第一直觉肯定是时区上的问题。于是检查了系统时区：

[oracle@xxxxx ~]$ ll /etc/localtime
lrwxrwxrwx 1 root root 35 Jun 1x  202x /etc/localtime -> ../usr/share/zoneinfo/Asia/Shanghai

[oracle@xxxxx ~]$ timedatectl
      Local time: Fri 2026-08-21 14:05:01 CST
  Universal time: Fri 2026-08-21 06:05:01 UTC
        RTC time: Fri 2026-08-21 06:05:01
       Time zone: Asia/Shanghai (CST, +0800)
     NTP enabled: yes
NTP synchronized: yes

结论：系统时区是 Asia/Shanghai (CST, +0800)，完全正确。✅

方向 2：怀疑 crontab 语法或环境变量

检查了 /etc/crontab 和用户的 crontab，语法标准，没有异常的环境变量覆盖：

[oracle@xxxxx  ~]$ cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

结论：语法和环境都没问题。✅

方向 3：怀疑 crond 服务配置

检查了 /etc/sysconfig/crond，没有额外的启动参数：

[root@xxxxx ~]# cat /etc/sysconfig/crond
# Settings for the CRON daemon.
# CRONDARGS= : any extra command-line startup arguments for crond
CRONDARGS=

结论：crond 配置正常。✅

方向 4：关键线索——crond 进程的启动时间

这是整个排查的转折点。查看 crond 进程信息时，发现了一个惊人的事实：

[oracle@xxxxx ~]$ ps -eo pid,lstart,cmd | grep crond
 5205 Wed Jun 1x 1x:0x:xx 2020 /usr/sbin/crond -n

crond 进程自 2020 年 6 月 1x 日启动后，已经运行了整整 6 年，从未重启过！

而 /etc/localtime 的符号链接时间戳也是 Jun 10 2020。这强烈暗示：crond 在 2020 年启动时读取了当时的时区，之后系统时区可能被修改过，但 crond 一直活着，始终沿用着启动时的旧缓存。

方向 5：验证测试的陷阱——* * * * * date 的误导

为了验证，我配置了一个每分钟执行的测试任务：

* * * * * date >> /tmp/crontab_test.log

日志输出：

Fri Aug 21 14:50:01 CST 2026

当时误以为这证明了 crond 时区正常。 但这是一个巨大的陷阱！

根据 Oracle Linux 官方文档的说明：

“Note that timezones are largely used for display purposes or to handle user input.”
—— Oracle Linux 7: System Date and Time Settings

date 命令作为短生命周期进程，每次执行时都会重新读取 /etc/localtime，其输出反映的是当前的系统时区（用于显示）。date 命令执行时动态读取 /etc/localtime，所以输出永远是当前的 CST 时间——这只能证明 date 命令的显示时区是对的，完全不能证明 crond 的调度时区也是对的。

两者的本质区别在于：

层面	date 命令	crond 守护进程
进程特性	每次执行都是全新的短生命周期进程	2020 年启动后一直运行的长生命周期进程
时区读取时机	进程启动时调用 tzset() → 读取当前 /etc/localtime	启动时读取并缓存，之后调度直接使用内存缓存
时区变更后	下次执行新进程，自动读取新的 /etc/localtime	仍使用启动时的旧时区数据
官方文档定位	“timezones are largely used for display purposes”	“long running processes…may not detect a subsequent change in system timezone”

Oracle Linux 官方手册（核心依据）《Oracle Linux 7 - Managing Core System Configuration》 和 《Oracle Linux 8 - Managing the System With systemd》 中均有明确说明：

“This command sets a symbolic link from /etc/localtime to point to the appropriate zone information file in /usr/share/zoneinfo/. The setting takes effect immediately. Some long running processes that might use /etc/localtime to detect the current system timezone, may not detect a subsequent change in system timezone until the process is restarted.”
—— Oracle Linux 7: System Date and Time Settings

同时该文档还指出：

“Note that timezones are largely used for display purposes or to handle user input. Changing timezone does not change the time for the system clock. You can change the presentation for system time in any console by setting the TZ environment variable. For example, to see the current time in Tokyo, you can run: TZ="Asia/Tokyo" date”
—— Oracle Linux 7: System Date and Time Settings

这两段话完美解释了为什么 date 的输出（显示层面）和 crond 的调度（进程缓存层面）会不一致：

• date 的时区输出属于 “display purposes”
• crond 作为 “long running processes”，在启动时缓存了时区，后续变更不会自动感知

方向 6：决定性验证——配置一个具体的非每分钟任务

为了真正验证，配置了一个具体的任务：

30 15 * * * date >> /tmp/crontab_test.log

当前系统时间是 15:24 CST，如果 crond 时区正常，15:30 会正常执行。但是到了15:35它没有执行。

这说明：crond 内部认为的 “15:30” 对应的实际 CST 时间是 23:30（UTC 15:30 + 8小时 = CST 23:30）。

至此，问题彻底确认：crond 在启动时缓存了 UTC 时区，后续系统时区变更为 CST 后，crond 的调度仍按 UTC 进行。

---

三、根因分析：两个"时区"不是一回事

这个问题的核心在于 Linux 中存在两个层面的"时区"：

层面	代表	读取时机	是否动态更新
系统时区	/etc/localtime	系统启动时建立	可手动变更（timedatectl set-timezone）
进程时区缓存	glibc 的 tzset() 缓存	进程启动时读取	不会自动更新
命令显示时区	date 等命令的输出	命令执行时调用 localtime()	每次执行重新读取

glibc 的时区解析机制

glibc 的 tzset() 函数在进程启动时会读取时区信息：

“If the TZ variable does not appear in the environment, the system timezone is used. The system timezone is configured by copying, or linking, a file in the tzfile(5) format to /etc/localtime.”
—— Linux man-pages, tzset(3)

“The <time.h> routines from glibc read from /etc/localtime to perform their functions.”
—— Red Hat Bugzilla

对于短生命周期进程（如 date 命令），每次执行都是新进程，自然每次都会重新调用 tzset()，重新读取 /etc/localtime，所以始终看到最新的系统时区。Oracle 官方文档也明确指出，date 命令的时区输出属于显示层面。

对于长生命周期守护进程（如 crond），启动时 tzset() 读取并缓存了时区规则（tzname、timezone、daylight 等变量），之后调度任务时直接使用内存中的缓存，不会反复重新读取 /etc/localtime。

---

四、解决方案

既然根因是 crond 启动时缓存了旧时区，解决方案非常简单：

# 重启 crond 服务，让它重新读取当前的 /etc/localtime
systemctl restart crond

# 验证：确认进程启动时间已更新
ps -eo pid,lstart,cmd | grep crond

# 验证：配置一个测试任务，观察是否按 CST 正确执行
30 16 * * * date >> /tmp/crontab_verify.log

重启后，crond 会按照 Asia/Shanghai (CST) 正确解析 。

---

五、总结与启示

• 修改系统时区后，务必重启相关长运行进程，尤其是 crond、syslogd 等守护进程。无法确定的话，可以重启操作系统。

---

一句话总结：在 Linux 中，date 命令看到的时区是"现在"的时区（显示层面），而 crond 的调度时区可能是"六年前"的时区（进程缓存层面）。当两者不一致时，不要怀疑你的眼睛，去怀疑那个从 2020 年活到现在还没重启过的进程——正如 Oracle 官方文档所说："long running processes…may not detect a subsequent change in system timezone until the process is restarted.