Alibaba cloud international server special offer

腾讯云服务器定时任务：crontab 时区、并发锁与容器里的 cron

"脚本我手动跑没问题，一放 crontab 就不动"，这句话我几乎每周都能从客户那儿听到一次。腾讯云服务器定时任务crontab 的问题，九成不是 cron 本身坏了，而是它运行的环境和你登录的 shell 根本不是同一个世界：时区、路径、环境变量、并发、日志，每一处都能让你"以为它在跑，其实它没跑"。这一篇就把这些坑按排查顺序讲清楚。

手动能跑、定时不跑：环境变量与 PATH 的坑

cron 执行任务时的环境变量非常干净，PATH 通常只有 /usr/bin 和 /bin，没有你写在 .bashrc、.bash_profile 里的那些路径；工作目录默认是用户家目录，不是脚本所在目录。于是就有了那些经典现象：

• 脚本调用了 /usr/local/bin 下的程序，手动能跑、定时找不到，解决方式是写全绝对路径，或在脚本开头显式导出 PATH。

• 依赖虚拟环境、conda、nvm 的任务，cron 拿不到这些初始化，要么在脚本里手动激活，要么封装成一个自带环境的入口脚本再让 cron 调。

• 相对路径的坑更隐蔽。脚本里写了 ./data/output.csv，登录时在家目录能对，cron 里工作目录一变就写到别处去了，用绝对路径，或在脚本里先切到固定目录。

• 密码、密钥这类环境变量也不在。别把敏感值硬写进 crontab 行，用受权限保护、属主为运行账号的配置文件读取。

我的习惯是：定时任务脚本的第一段永远是设 PATH、切到固定目录、加载环境文件，然后才干活。cron 和你登录的 shell 是两套环境，任何"手动能跑"的结论都不算数。

顺带说一个权限相关的坑：任务的运行身份取决于这条 crontab 属于哪个账号，不是你以为的 root。用 root 的 crontab 去跑数据库备份，生成文件的属主可能就是 root，应用账号反而读不了，表现为"备份文件明明在，恢复时却没权限"。建议用一个专用的服务账号统一管理定时任务，属主和权限在上线前一次定死。

还有一件基础但常被跳过的事：先把 cron 的日志确认到能看。多数发行版会把调度事件记到 /var/log/cron 或 /var/log/syslog，至少要保证系统日志服务在跑，否则任务失败时你连一条线索都没有。

cron 表达式与时区：差 8 小时的翻车

cron 表达式共五段，依次是分、时、日、月、周，但它挂在哪条时间轴上，取决于系统时区。云服务器 CVM（行业里常叫 ECS）的默认时区不少是 UTC，如果你按北京时间写 0 2 * * *，以为凌晨 2 点执行，实际会在 UTC 2 点跑，也就是北京时间上午 10 点，日志时间对不上，业务时间也对不上；反过来客户喊"任务没跑"，常常只是没在他以为的点上跑。

排查手段我一般按这个顺序：

• 看系统时区，用 timedatectl，或看 date 命令的输出里带不带 UTC 字样。

• 想让任务按指定时区走，可以在 crontab 顶部设置 CRON_TZ=Asia/Shanghai，不过不是所有 cron 实现都支持；更稳妥的做法是把系统时区统一改成 Asia/Shanghai，并保证所有机器一致。

• 别用 @daily 去赌触发点，它的具体时刻由实现定义，换版本可能就变了。

我一般要求同一批机器的时区全部对齐，脚本里涉及时间的逻辑统一用带时区的写法，避免"容器 UTC、宿主机 CST、数据库又是另一种"的三方错位，那种排起来最费劲。

还有一个容易忽略的细节是夏令时。像 America/New_York 这类时区在切换日会出现某两个小时重复或跳过，用本地时区写死时刻的任务可能重复执行或整点漏执行。业务一旦跨这些时区，我更倾向让调度统一基于 UTC 计算，只在展示层换算成本地时间。

另外，cron 的"日"和"周"两段是或的关系，不是与。写 0 0 1 * 1 想表达"每月 1 号且是周一"，实际效果却是"每月 1 号"或"每周一"都会触发，很多脚本重复跑就是这么来的。这种歧义在 systemd timer 里不明显，因为 OnCalendar 的语义更明确。

并发重叠与 flock 加锁、误删数据复盘

任务执行时间超过调度间隔就会重叠。比如每 5 分钟一次的任务，某次跑了 12 分钟，第二个实例又起来了，两个进程同时处理同一批数据，轻则重复处理、重则互相覆盖，最坏是数据被删。防止重叠最省事的办法是 flock 加锁，直接在 crontab 行里写：每 5 分钟触发时用 flock 的 -n 参数去抢 /var/lock/sync.lock，抢不到就跳过，命令行用 -c 把真正的脚本包起来。注意锁文件要放在运行账号有权限、且所有实例一致可见的路径上。

失败要有人知道。cron 默认把任务输出通过本机邮件发给用户，但多数服务器没配邮件，等于静默失败。我的做法是脚本里明确写日志、开头加 set -e，退出码非 0 时通过告警通道通知，而不是等业务方第二天来问数据为什么没更新。

误删数据的案例我印象很深：一个客户用 find 清理临时文件，命令里"删除超过 7 天的文件"写得好好的，结果脚本中临时目录变量拼错，展开后路径为空，find 直接对整个数据根目录生效。定时任务误删的破坏力远大于手动误删，因为它无人值守，还能反复执行。凡是带删除、覆盖的定时任务，先把目标挪到隔离目录、先备份、先在测试环境跑一遍，再上生产。

清理类任务还有两条铁律：先输出将要删除的清单，人工确认或自动比对数量落在预期范围内，再去真正删除；对目录一定要先判断存在且非空，并配合 set -u 让未定义变量直接报错退出，避免变量为空把路径退化成根目录。

再补一个思路：并发重叠的根不是锁，而是任务本身没做幂等。如果每次执行都先判断"这批数据是否已经处理过"，重复跑也不会出事，那即便偶尔重叠也不至于翻车。加锁是防弹衣，幂等才是安全带，两个都得有。

锁的粒度也要想清楚：你要的是"同一任务不许重叠"，还是"同一份资源只能有一个任务访问"。如果是后者，用一把共享的锁文件更合适，别每个任务各锁各的，结果还是互相踩。

错过执行、anacron 与 systemd timer 的取舍

机器关机或重启期间错过的任务，传统 cron 不会补跑，任务是"到点触发"，错过就错过了。anacron 能补齐按天、按周这类周期任务，但它精度只到天，不适合分钟级调度。对关键任务，我会在脚本里做幂等加补数据校验，而不是指望调度器帮我补。

现在更推荐用 systemd timer 替代 cron，两者的差别看这张表：

对比项 crontab systemd timer

时区控制 依赖系统时区或 CRON_TZ 单元内可显式设置

错过补跑 不支持 设 Persistent 可补跑

日志查看 需自己重定向到文件 journalctl 统一查看

依赖编排 需脚本自己处理顺序 用 After 与 Requires 编排

失败告警 需自己在脚本里做 用 OnFailure 触发告警单元

并发控制 靠 flock 等外部手段 服务单元天然单实例

表里的补跑和失败告警是我最看重的两点：错过能补、失败能喊。代价是入门比 crontab 稍麻烦，要写服务单元和定时单元两个文件。

从 crontab 迁移到 systemd timer 时有几个细节要注意：定时单元里 OnCalendar 的写法比 cron 表达式直观，但语法完全不同，别照搬；Persistent 只对错过的触发点补跑一次，不会把历史上错过的全部补一遍；真要实现失败告警，还得单独写一个告警服务单元，由 OnFailure 去引用它，光设个开关是没用的。迁移时别一次性全换，先把一类任务在 timer 上跑稳，再逐步搬过去，出问题也更容易定位是哪一批受的影响。轻量应用服务器上任务不多的话，crontab 也够用，但要记得自己补齐日志与告警这两块短板。

容器里跑 cron：PID 1 与 /etc/localtime

容器里跑 cron 有两个高频坑。

• PID 1 的问题。容器里如果直接以前台 cron 进程启动，它就变成 PID 1，收到停止信号时不一定能把子进程收干净，退出会变慢甚至卡住。更常见的做法是让业务进程当 PID 1，把 cron 放到独立的 sidecar 容器，或者引入能正确处理信号转发的 init 进程。

• 时区不生效。容器基础镜像默认 UTC，你设置了 TZ 变量却没装 tzdata，或者挂载了路径但没生效，任务时间照样错。要么把宿主机 /etc/localtime 挂进容器，要么在镜像里装好 tzdata 并设置 TZ，两条路选一条并且用 date 验证。

还有一点容易忽略：cron 在容器里读的是容器内的 crontab，不是宿主机的；任务能访问的环境边界也不同。跨容器跑任务时，时钟一致性、日志要落到宿主机的哪个路径，都得提前想清楚，否则出问题时连日志都找不到。容器里 cron 的日志默认跟着前台走，容器一被重建日志就没了，要么把日志目录挂成宿主机卷，要么接入集中日志。

还有一种更省心的做法：干脆不在容器里跑 cron，把定时触发交给平台级调度，容器只负责执行一次性任务，跑完即退。这样既没有 PID 1 的烦恼，也天然具备重试与日志归集。

FAQ

Q：crontab 里脚本没执行，第一件该查什么？

A：先查 cron 日志，在 /var/log/cron 或 /var/log/syslog 里能看到它有没有调到这条任务、报了什么错。再看环境变量与 PATH、命令有没有写绝对路径、脚本是否有可执行权限。

Q：怎么确认定时任务用的时区是对的？

A：在任务脚本里打印 date +%Z 和 date，和业务需要的时区比对；同时用 timedatectl 确认系统时区；容器内还要确认挂载了 /etc/localtime，或在镜像里装了 tzdata 并设置了 TZ。

Q：任务执行时间超过了调度间隔怎么办？

A：用 flock 的 -n 参数加锁避免重叠，拿不到锁就跳过本次。如果任务本身就耗时长，要么拉长间隔，要么把长任务拆成可并行的分片，别让实例无限堆叠。

Q：cron 和 systemd timer 到底选哪个？

A：机器少、任务简单、依赖轻，crontab 够用；需要错过补跑、统一日志、失败告警和依赖编排，systemd timer 更合适。关键任务别只依赖调度器，脚本本身要做幂等和数据校验。

Q：定时任务怎么保证日志不丢，还能及时报警？

A：脚本里把标准输出和标准错误重定向到带日期的日志文件，配合 logrotate 轮转；同时让脚本失败时返回非 0 退出码，由告警通道或 systemd 的 OnFailure 捕获后通知到人。

结语

可执行的建议就四条：把所有定时任务脚本改成"设 PATH、切绝对目录、记日志、flock 加锁"四件套；统一全部机器的时区并在脚本里验证；给每个任务配一个失败告警通道；涉及增删改的任务先在测试环境跑一遍再上生产。别小看这四件事，它们几乎覆盖了我处理过的绝大多数"定时任务不听话"的报障。做完这些，腾讯云服务器上的定时任务才算真正可靠，而不是靠运气运行。这也是为什么建议在腾讯云账户开通阶段，就把时区规范和监控告警规划一起定下来，能省掉后面一堆半夜起床救火的麻烦。

如果需要更深入咨询了解可以联系全球代理上TG:jinniuge 他们在云平台领域有更专业的知识和建议，他们有国际阿里云，国际腾讯云，国际华为云，aws亚马逊，谷歌云一级代理的渠道，客服1V1服务，支持免实名、免备案、免绑卡。开通即享专属VIP优惠、充值秒到账、官网下单享双重售后支持。不懂找他们就对了。