Docker容器时间漂移与crond定时任务错乱：TZ与宿主时间源协同

发布时间：2026-09-21 12:31 更新时间：2026-09-21 12:31 阅读量：0

不少站长都遇到过这种情形：宿主机上 date 看着没问题，容器里的备份脚本、清理脚本却总是提前或延后几个小时执行，日志时间戳也和现实对不上。更让人困惑的是，把容器重启一次好像又正常了，过一阵子又漂了。这类问题通常不是 crontab 语法写错，而是容器内部的时间源、时区设置和宿主机之间没有对齐。本文把容器时钟的来源讲清楚，再给出 crond 在容器里跑定时任务的可用配置与验证步骤，让新手能照着做，老手也能顺手排查掉几个常见坑。

容器的时间从哪来：内核时钟与时区是两件事

先分清两个概念。第一是系统时钟（wall clock），也就是“现在几点几分几秒”，它由 Linux 内核维护，所有容器共享同一个内核时钟，所以容器的绝对时间一般和宿主机一致。第二是时区，时区只是把同一个时间戳换算成哪个地区的地方时来显示。时间戳本身是 UTC，不带时区信息。

所以“容器时间漂移”要拆成两种情况：一种是真实的时间戳漂了，多半是宿主机没做时间同步，或者虚拟机被暂停/迁移后时钟跳变；另一种是时间戳没变，只是容器读到的时区不对，导致日志和 cron 按 UTC 而不是本地时间计算，看起来就像“漂了几小时”。日常遇到的绝大多数是后者。

容器里默认的时区来自镜像本身。很多精简镜像（比如 alpine、debian-slim）里没有 /etc/localtime 或它指向 UTC，容器里 date 就直接显示 UTC。宿主机的 /etc/localtime 并不会自动映射进容器，这一点是新手最容易误判的地方。

配置 TZ 与挂载 localtime：让容器按本地时区走

最直接的办法是给容器传入 TZ 环境变量。TZ 被 libc 和多数程序读取，date、cron 都会受影响。以 docker run 为例：

docker run -d --name app \
  -e TZ=Asia/Shanghai \
  -v /etc/localtime:/etc/localtime:ro \
  nginx:stable

这里同时做了两件事：-e TZ 告诉程序用哪个时区，-v /etc/localtime:ro 把宿主机的时区文件只读挂进容器，让依赖 /etc/localtime 的程序也能拿到正确时区。两者配合比只设其中一个更稳妥。注意 /etc/localtime 通常是软链接或时区二进制文件，挂载时保持只读，避免容器内程序误改宿主机时间配置。

如果用的是 Docker Compose，写法类似：

services:
  app:
    image: nginx:stable
    environment:
TZ=Asia/Shanghai
    volumes:
/etc/localtime:/etc/localtime:ro
/etc/timezone:/etc/timezone:ro

改完之后别急着看 date 就下结论，先确认三处一致：宿主机 timedatectl 显示的时区、容器内 date 的输出、以及业务日志里写入的时间戳。三处都对齐了，才算真正配好。如果宿主机本身没开 NTP/chrony 同步，容器时间也会跟着宿主一起漂，那是另一个层面的问题，建议先保证宿主机时间源正常，具体同步方式以各发行版官方文档为准。

容器里跑 crond：为什么它不认时区、又该怎么验证

很多人把 crontab 写进容器后，发现任务按 UTC 触发，比预期早了 8 小时。原因是部分 cron 实现在启动时读取一次时区，之后进程环境里没有 TZ，就退回到系统默认。所以光在 docker run 时加 -e TZ 还不够，关键是让 cron 进程自身也处在正确的时区环境里。

一个常见做法是在容器启动脚本里显式导出 TZ 再启动 crond，例如用 alpine 的 busybox crond：

#!/bin/sh
set -e
export TZ="${TZ:-Asia/Shanghai}"
打印一次便于排查，确认环境变量生效
date
前台运行 crond，日志打到 stdout
exec crond -f -l 8

用 exec 让 crond 成为 PID 1，日志直接进 docker logs，方便确认任务有没有被触发。crontab 内容按本地时间写即可，例如每天凌晨 3 点做一次清理：

# 在容器内执行 crontab -e，或用镜像里的 /etc/crontabs/root
0 3 * * * /usr/local/bin/cleanup.sh >> /var/log/cleanup.log 2>&1

验证时有几个动作值得养成习惯。进容器执行 date 和 date -u，两个输出相差正好是时区偏移，说明 TZ 生效；再 cat /etc/crontabs/root 看任务是不是按本地时间写的；最后等一次触发窗口，用 docker logs 看 crond 有没有输出执行记录。如果任务一直不触发，优先怀疑 cron 进程没起来或时区文件缺失，而不是怀疑表达式写错。

还有两个容易踩的坑。一是别在容器里同时用宿主 cron 和容器 cron 跑同一件事，两边时区不一致时会出现重复执行或互相覆盖。二是容器重启后时间环境会重置，如果 TZ 只写在一次性的启动命令里，重建容器就丢了，建议把 TZ 固化到镜像的 Dockerfile 或编排文件的环境变量中。涉及系统时间调整的操作，尽量在宿主机统一做，容器内不要随意改时钟。

小结与下一步

容器时间问题拆开看就两条线：真实时钟靠宿主机的时间同步保证，显示时区和 cron 计时靠 TZ 与 /etc/localtime 协同解决。排查顺序建议是——先看宿主机 timedatectl 是否正常同步，再看容器内 date 与 date -u 的偏移，最后确认 crond 进程是否带着正确的 TZ 启动、日志里有没有触发记录。把这三步做成固定的检查清单，以后再遇到“定时任务错乱”，基本几分钟就能定位。若你的定时任务涉及数据库备份、证书续期这类对时间敏感的操作，建议额外在业务侧记录一次任务开始时间，方便和容器时间对照。

继续阅读