Linux定时任务不执行？排查crontab常见坑与解决方案

1. 定时任务最扎心的一刻：写了，却没跑

先聊个普遍场景：你花十分钟写好一个脚本，手动执行一切正常，数据、日志、输出全都符合预期。于是你满怀信心地加了条 crontab，设成每天凌晨 3 点跑，结果第二天早上打开电脑一看，啥都没发生，连个报错痕迹都找不到。那种感觉，就像你给朋友发了条消息，对方“已读”了，但就是没回你。

其实定时任务没执行这件事，绝大多数情况下不是 cron 本身坏掉了，而是我们对 cron 的运行机制存在几个固定的误解。我说句实在话，这几年帮别人排查过的“定时任务不执行”问题至少有几十次，每次翻来覆去都逃不出那么几个原因：环境变量对不上、权限不够、路径写错、服务没起来、时区整岔了。但有意思的是，每次换个人来问，描述出的现象都有点不一样，导致很多人会绕很多弯路，甚至有人最后把 crond 卸载重装一遍才发现问题出在脚本第一行的换行符上。

这篇文章我打算把定时任务不执行这件事彻底讲透：先搞清楚 cron 到底是怎样一种存在，再把最常见的几类“真凶”挨个过一遍，最后给你一套我自己一直在用的排查流程和避坑清单。你看完应该能少走不少弯路，至少再碰见同类问题，能有一个清晰的排查思路，而不是对着服务器反复重启。

说明一下，这篇文章主要围绕 Linux 环境下的 crontab 来讲，同时会带一点 systemd timer 的对比，因为这些是日常运维中最常接触的方案。

2. 先搞清楚：cron 到底在什么样的环境下跑命令

2.1 cron 不是“用户登录后再执行”，而是“独立拉起任务”

很多人第一次接触定时任务时，脑子里默认了一个概念：机器到了指定时间，就像有人坐在终端面前，打开 Shell，敲下你的命令。这个想象听着合理，但它在原理上就是错的。cron 是一个后台守护进程，由 init 或 systemd 在系统启动时拉起，它平时一直驻留内存，每分钟醒来一次，检查当前时间是否匹配某个任务定义。一旦匹配，它会直接 fork 出一个子进程来运行你配置的命令或脚本。

这个“独立拉起”的特点是：它不会加载你的登录 Shell 配置，不会读取你的~/.bashrc、~/.bash_profile，也不会继承你在终端里手工 export 的那些环境变量。它给你的脚本提供的，只是一个极度精简的初始环境。很多人之所以手动执行脚本好好的、一进 cron 就挂，根因恰恰在这里。

你可以做一个实验，在 crontab 里加上这么一条：

* * * * * env > /tmp/cron_env.txt

等一分钟后，打开/tmp/cron_env.txt看看，里面的 PATH 大概率只有/usr/bin:/bin这种基础值。而你手动执行时，PATH 可能是/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin这样一大串。这差距意味着你在脚本里直接敲某个命令名，cron 环境可能根本找不到它。

2.2 cron 解释命令的方式也和你想象的不一样

crontab 里每行任务分六个字段，前五个是时间部分，分别代表分、时、日、月、周，第六个字段就是要执行的命令。这里有个细节：如果你写的是一个命令字符串，cron 会交给默认 Shell 去解释，比如sh -c，而不是直接 exec。这个机制本来是为了方便大家用管道、重定向、变量展开这些 Shell 特性，但它也带来一个副作用：如果默认 Shell 配置异常，或者脚本里用了某个 Shell 特有的语法，可能整个任务就崩了。

还有一点，cron 对退出状态是敏感的。如果任务执行完返回非零状态码，有些 cron 实现会把这段异常记录到日志，甚至通过邮件发给用户。默认情况下，如果没做任何输出重定向，脚本的任何 stdout 或 stderr 内容都会被 cron 收集起来，尝试发送到本地邮箱——也就是/var/spool/mail/用户这个位置。很多人平时根本不看这个邮箱文件，导致任务其实一直在执行、一直在报错，但主人完全不知情。

2.3 三种常见定时任务形态要先对号入座

在进入排查之前，我还想先帮大家理清一个概念：不是你写的所有“定时任务”都是 crontab。日常工作中常见的定时任务至少有三种形态，每种形态的排查路径完全不同：

形态	配置入口	典型场景	排查入口
crontab 任务	crontab -e或/etc/crontab	普通脚本定时跑、日志清理、数据备份	/var/log/cron，journalctl -u crond
systemd timer	.service+.timer文件	较新系统上替代 cron 的现代方案	systemctl status 服务名.timer
应用内部调度	代码里的schedule/celery beat/quartz	业务系统自带的定时任务	应用日志、任务队列状态

很多人跑来跟我说“我的定时任务不执行”，最后查了半天发现是 systemd timer 的手写配置文件有语法错误，这跟 crontab 完全是两套排查逻辑。所以第一步，永远是先确认你用的到底是哪一种。

3. 环境变量与解释器差异：第一类高频真凶

3.1 PATH 缺失导致“命令找不到”

这回说我一个实际经历。有次同事写了个备份脚本，里面一行是mysqldump -u root database > /backup/db.sql，手动执行没问题，加到 crontab 里就是不生成备份文件。查了半天日志，发现每次执行都报command not found。原因就是 mysqldump 装在/usr/local/mysql/bin，而 cron 环境下的 PATH 根本没有这个目录。

解决方案说穿了也不难，三种做法任选：

第一，脚本里所有外部命令全部写成绝对路径：

/usr/local/mysql/bin/mysqldump -u root database > /backup/db.sql

第二，在脚本开头主动导出一份标准 PATH：

#!/bin/bash export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

第三，在 crontab 里直接指定 PATH 变量。crontab 文件支持在任务之前设置环境变量，比如：

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 15 2 * * * /root/scripts/backup.sh

我个人最推荐第二和第三种组合使用。脚本内导出 PATH，可以保证脚本在人工执行和定时执行两种场景下表现一致；crontab 里设置 PATH 则能覆盖所有命令场景，包括那些不是通过脚本执行的单行命令。

3.2 登录 Shell 与非登录 Shell 的环境差异

顺着上面继续说，PATH 只是环境差异的一部分。很多软件安装时会要求你把环境变量写进~/.bashrc或/etc/profile.d/，比如 Java 的JAVA_HOME、Python 虚拟环境的激活脚本、NVM 的路径声明。这些配置在你开个终端时都会生效，你以为全局都知道，其实只存在于登录 Shell 的上下文里。

cron 执行任务时用的是非登录、非交互式 Shell，它不会去读/etc/profile、不会读~/.bash_profile、~/.bashrc也未必会读。所以凡是依赖这些配置才能运行的程序，放进 crontab 基本都会“失忆”。

解决思路有两个：要么在脚本开头重新 source 一遍环境配置，要么把运行所需的环境变量直接硬编码到脚本里。硬编码最省心，也最可预测。比如：

#!/bin/bash export JAVA_HOME=/usr/local/java/jdk17 export PATH=$JAVA_HOME/bin:$PATH

3.3 脚本解释器指向不明或解释器缺失

还有一个容易被忽略的点：脚本第一行的 shebang。假设你写了一个脚本，开头写的是#!/usr/bin/env python，手动执行没问题，但到了 cron 环境下，env可能在 PATH 里找不到 python——因为 python 在某个虚拟环境里。此时脚本直接报错退出。

更隐蔽的情况是脚本没有 shebang。没有 shebang 的脚本，cron 会用默认 Shell 去执行，也就是sh。如果你的脚本里写的是 Bash 特有语法，比如[[ ]]、source、数组、function关键字，sh 解释器可能直接语法报错。我之前就见过有人写了个脚本，里面用了[[ $1 == "a" ]]，手动用bash script.sh执行一切正常，但 cron 调它时报unexpected EOF，追到根因就是 shebang 缺失、脚本被 sh 解释。

这类问题建议这么处理：

#!/bin/bash

明确写上你期望的解释器，同时确保解释器的绝对路径是存在的，执行权限也给了。你可以在脚本头部加一句校验逻辑，比如：

#!/bin/bash command -v python3 >/dev/null 2>&1 || { echo "python3 not found"; exit 1; }

这样即使环境有问题，至少能在日志里留下明确信息，而不是默默失败。

4. 权限、路径与文件格式：第二类高频真凶

4.1 执行权限缺失与属主问题

crontab 执行一个脚本，本质上就是一个进程去尝试执行脚本文件。脚本文件如果没有执行权限，也就是没有 x 位，那必然报Permission denied。这种问题在 Windows 上传脚本到 Linux 服务器时尤其常见，因为很多人在 Windows 上编辑完脚本，直接通过 SFTP 上传，文件的权限默认为 644，也就是只有读写权限、没有执行权限。

解决方法很简单：

chmod +x /path/to/script.sh

你也可以在 crontab 里避免直接执行脚本文件，改成用解释器运行，比如：

30 2 * * * bash /path/to/script.sh

这种方式绕过了执行权限限制，但要注意它同时也绕过了 shebang 的选择逻辑，等于强制用 bash 来解释。

属主问题也同样重要。某用户把脚本放在自己的家目录，权限是 700，其他用户甚至 root 的 crontab 来执行这个脚本时，进程没有权限读取脚本内容。这种报错比较诡异，日志里通常只会给你一句No such file or directory，但文件明明就在那儿。务必检查：脚本属主是不是执行 cron 的那个用户，至少要让执行用户对脚本有读权限。

4.2 相对路径的隐形炸弹

这是我认为最容易犯、也最不明显的一类错误。你在 crontab 里写了这样一条：

0 1 * * * ./backup.sh

或者脚本内部写了：

mv data.csv /backup/

问题是，cron 执行命令时的工作目录是哪里？答案是：取决于 crontab 实现。有些系统默认是用户家目录，有些是/，总之它不会自动切到你脚本所在的目录。于是./backup.sh这个写法就成了“在某个未知目录下找 backup.sh”，一旦找不到，任务就失败得很干脆。

正确的做法是，脚本内部绝对不要依赖相对路径，所有输入输出路径都写成绝对路径。如果非要在脚本里定位“当前脚本目录”，再用下面这种写法：

SCRIPT_DIR=$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd) cd "$SCRIPT_DIR"

但即便有了这个，日志输出路径、引用的数据文件路径，也建议全部显式写绝对路径。这不是强迫症，这是给未来的自己省时间。否则半年后你回来看这个脚本，根本猜不到它执行时的工作目录是哪。

4.3 Windows 换行符与编码残影

Windows 下写的脚本文件，每一行末尾是\r\n（CRLF），Linux 是\n（LF）。当你把 Windows 下编辑的脚本传到 Linux，并试图用bash script.sh执行，解释器会把\r当作命令内容的一部分，导致各种奇怪的错误。比如一个正常的echo "hello"，在 CRLF 下可能被解析成echo "hello"\r，常见报错是$'\r': command not found，但有时候它并不会直接报错，而是让逻辑进了一个莫名其妙的分支，非常难排查。

排查方法很简单：

file script.sh

如果输出里有with CRLF line terminators，那就说明换行符有问题。修正可以用 sed 或 dos2unix：

sed -i 's/\r$//' script.sh # 或 dos2unix script.sh

还有编码问题。脚本里如果带中文注释，文件编码若不是 UTF-8，某些环境下解释器也可能出问题。建议所有脚本统一 UTF-8 无 BOM，编辑器设成 Linux 换行符，从根上杜绝这类问题。

4.4 脚本中有交互式命令或等待输入

这个也值得单独拎出来说。cron 环境是没有终端的，也是无交互的。如果你的脚本里有一条命令需要用户确认，比如rm -i、cp -i，或者某个程序会读取 stdin 等用户输入，在 cron 环境下它不会得到输入，可能会直接停在原地，或者因为无法读取输入而跳过关键步骤。

解决办法是给命令加上非交互选项，比如：

rm -rf /backup/old_files cp -r /src /dst

或者在命令前加上</dev/null，阻断脚本对终端的依赖：

/path/to/script < /dev/null

顺带说一句，脚本里如果调用了交互式命令但没有加-y这类参数，不只是 cron 跑不动，命令行管道里跑也可能卡死，这类习惯越早改越好。

5. 服务状态、时区与系统机制：第三类高频真凶

5.1 crond 服务压根没跑起来

你可能会觉得“crond 服务没起”是幼儿园问题，但现实中这种事真的不少。尤其是容器化环境里，很多基础镜像默认不会启动 crond 服务，或者 Dockerfile 里没写 CMD 去启动它。你在容器里crontab -e编辑了任务，以为万事大吉，结果容器里根本没有 cron 守护进程在运行。

再比如某些刚装好的最小化系统，cron 软件包都没装。你执行crontab -e时系统可能会提示找不到命令，但如果你用别的编辑器改了/etc/crontab文件，系统可能也不会有任何反馈，因为根本没有服务读取这个文件。

检查方法如下：

# systemd 系统 systemctl status crond.service # 传统 SysV 系统 service crond status # 查看进程 ps -ef | grep crond

如果服务没跑，启动它：

systemctl enable --now crond.service

需要提醒的是，不同发行版的服务名可能不同，有叫crond的，有叫cron的，还有叫crond.service的，查的时候多搜一下不会错。

5.2 编辑了 crontab 但服务没重新加载

这个可能很多人都没意识到：cron 守护进程会周期性重读 crontab 文件，但这个周期因实现而异。Vixie cron 默认每分钟检查一次文件时间戳，所以理论上你编辑完，最多等一分钟就会生效，不需要手动重启服务。但如果你手动改了/etc/crontab或/etc/cron.d/下的文件，同样也有生效延迟。

问题出在另一种情况：你编辑的是某个用户自己的 crontab，但当前系统的 cron 实现是某些精简版或非标准版，它并不自动监听 crontab 文件变化，必须重启服务才生效。好在这种情况在主流发行版里比较少见，但如果你的环境高度定制化，别忘了重启服务试一下。

顺带一提，crontab -e编辑的是当前用户的 crontab，而/etc/crontab是系统级 crontab，它多了一个用户字段。很多人会把两者记混，写了任务发现不执行，最后才发现根本没写到该写的地方。

5.3 时区错乱导致任务执行时间完全不对

这条必须重点说。要知道 cron 判断执行时间靠的是系统本地时间，也就是内核时间加上时区偏移。很多云服务器默认系统时区是 UTC，而我们习惯用的是北京时间，也就是 UTC+8。如果你在服务器上date看到的时间是 UTC 时间，而 crontab 里的时间按北京时间理解，那所有任务都会晚 8 个小时执行。

比如你写了0 3 * * *，本以为是凌晨 3 点跑，结果服务器是 UTC 时区，任务会在北京时间上午 11 点跑。如果任务是白天执行的，影响可能不明显；如果任务是凌晨执行的备份，你第二天一早去查数据，大概率会发现“昨晚的任务到底跑没跑？”——跑了，但时间不对。

检查时区：

date timedatectl

如果时区不对，改成中国标准时间：

timedatectl set-timezone Asia/Shanghai

有些容器环境没有 timedatectl，那可以直接通过软链时区文件：

ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

修改完时区后，别忘了确认 crontab 里的时间预期是否正确。另外还有一点，cron 在夏令时切换的时候行为很特殊，有些地区时间会跳变，不过国内没有夏令时，这个对大部分读者影响不大，但在做跨境系统时要注意。

5.4 anacron 与系统休眠机制吃掉任务

cron 的设计假设是系统 7x24 小时开机，它只在每个整分钟时刻醒来检查一次。但如果你的机器是笔记本、或者经常休眠、或者关机过夜，那半夜 3 点的任务在机器休眠时根本不会执行。等第二天开机后，cron 也不会补跑，因为它的执行条件已经过去了。

Ubuntu 这类发行版默认装了 anacron，它的作用就是弥补这个空档：如果系统错过了一次任务，anacron 会在下次开机后的某个延迟时段补跑一次。但 anacron 只认/etc/anacrontab里配置的任务，不认用户 crontab。所以如果你的环境是笔记本、虚拟机经常挂起，考虑把任务迁到 anacrontab，或者直接使用 systemd timer 加上Persistent=true属性，让任务在错过周期后启动时自动补跑。

systemd timer 这种做法好处很大，我简单给个示例：

[Unit] Description=Run backup script daily [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target

对应的 service 单元写好后，用systemctl enable --now backup.timer启动。错过执行时间后，下次开机系统会看到 Persistent=true，自动补跑一次。这点比 cron 优雅很多。

6. 实操排查流程：从现象到根因的六步走

6.1 第 1 步：确认 cron 服务与基本状态

先排查最底层的问题。查看 cron 服务进程是否存在，这个不能跳过，任何排查都应该从这里开始。

ps -ef | grep cron systemctl status cron # 或 crond

如果服务不存在，确认是否已安装：

which crontab

如果没有，用对应包管理器安装。apt 系执行apt install cron，yum 系执行yum install cronie。

确认服务正常后，看看当前用户的 crontab 里到底有什么：

crontab -l

顺带确认一下当前用户有没有被 cron 拒绝。部分系统会通过/etc/cron.allow和/etc/cron.deny控制用户能否使用 crontab，如果你的用户名被写进 deny 文件，那crontab -e会直接报错。一般运维环境不会配置这种限制，但你不确定时最好看一眼。

6.2 第 2 步：查看 cron 执行日志

日志是排查的第一入口。不同发行版日志位置略有差异：

• Ubuntu/Debian：/var/log/syslog，可以过滤 cron 字样
• CentOS/RHEL：/var/log/cron
• systemd 系统：journalctl -u cron或journalctl -u crond

我自己用的命令一般是：

grep CRON /var/log/syslog tail -n 50 /var/log/cron journalctl -u cron --since "1 hour ago"

日志会显示任务到没到执行点、命令是否启动、是否有报错信息。如果日志里压根没有你的任务记录，说明你的任务根本没被 cron 读取到，或者时间表达式不匹配。如果日志里显示任务已拉起，但没有输出信息，那就说明问题大概率出在脚本本身。

这里有个值得注意的小细节：日志可能不会显示所有标准输出，只有 cron 在尝试发邮件失败、或者执行记录异常时，才会有明确日志。所以日志看不到东西，不一定代表任务没执行，也可能是执行成功但静默了。为了确认，就要靠下一步的输出重定向。

6.3 第 3 步：给任务加上输出重定向，固定抓取证据

如果任务本身没有日志，你就无法判断它执行到了哪一步。所以排查前最好先给任务临时加上重定向：

* * * * * /bin/bash /root/scripts/test.sh >> /tmp/test_task.log 2>&1

注意* * * * *是一分钟跑一次，方便快速验证。等一分钟，看/tmp/test_task.log里有没有内容。

这个技巧的本质，是把 cron 丢弃的 stdout/stderr 强制落到文件里，这样无论脚本报了什么错，你都能看到原文。很多人在这一步就会发现问题：可能是command not found、可能是权限不足、可能是路径缺文件。

还有一个小技巧：在脚本开头加个标记时间戳的语句，确认脚本是否进入执行：

#!/bin/bash echo "$(date '+%F %T') script started" >> /tmp/marker.log

这样即使脚本中途失败，你也能确认“cron 确实拉起了脚本”，把问题范围缩小到脚本内部。

6.4 第 4 步：手动模拟 cron 的执行环境

手动执行脚本没问题，不代表 cron 环境执行没问题。为了更接近真相，可以构造一个和 cron 类似的干净环境来执行脚本：

env -i /usr/bin/env bash /root/scripts/test.sh

env -i的意思是清空所有环境变量，然后重新用 bash 执行。这样可以模拟 cron 那套“没有用户环境变量”的裸环境。如果在这个环境下脚本报错，那基本可以断定是环境变量或解释器问题。

如果这个裸环境下脚本能正常跑完，再结合日志输出，基本就能锁定问题方向。剩下的就是把脚本里的依赖路径改成绝对路径，或者把需要的环境变量在脚本里显式设置，然后再次用env -i验证。

6.5 第 5 步：调试脚本内部逻辑与退出状态

如果脚本被 cron 拉起了、日志也能输出，但执行结果不对，那就要进脚本内部调试了。比较简单粗暴的方式是加set -x，打印每一步执行过程：

#!/bin/bash set -x

然后在脚本最后加一句捕获退出状态：

echo "exit code: $?" >> /tmp/script_debug.log

这样你能完整看到脚本从头到尾的执行流程、每个变量的取值、每条命令展开后的形态。很多逻辑问题，比如 if 判断没进分支、变量为空、文件不存在，都能在这一步暴露出来。

另一种方式是用bash -n做语法检查，专门排查语法错误：

bash -n /root/scripts/test.sh

没有输出就说明语法没问题。有输出，会直接告诉你第几行有什么问题，通常是unexpected token或unexpected EOF，多见于引号未闭合、if 语句缺 fi、函数缺结尾。

6.6 第 6 步：用系统邮件或状态目录确认执行结果

如果前面几步都排查完还是没头绪，别忘了检查一个地方：/var/spool/mail/或/var/mail/下的用户邮件文件。cron 默认会把任务的 stdout 和 stderr 发送给任务属主，如果这些内容一直积累，你其实可以在邮件文件里看到每次执行的真实输出和报错。

有些人可能觉得“我从来没写过邮件相关配置”，但 cron 发送邮件用的是系统自带的 sendmail 或 postfix，很多基础镜像里是没装邮件服务的，这时邮件发送会失败，但这个尝试过程本身也有可能把 cron 的日志信息记录到系统日志。你查看：

tail -n 100 /var/mail/root

如果这里有一堆未读的“邮件”，实际上就是定时任务的历史输出。这也是排查时很容易被忽视的线索来源。

7. 常见问题速查表与避坑清单

7.1 高频问题速查

现象	最可能原因	快速验证	解决方案
任务完全没执行，没有任何日志	cron 服务没运行	systemctl status crond	启动并设为开机自启
日志显示command not found	脚本内命令依赖的目录不在 cron 的 PATH	手动env -i执行	脚本内显式 export PATH，或命令写绝对路径
明明到点了就是不跑，时间不对	系统时区是 UTC	date查看时间	修改时区
手动执行行，cron 执行失败	脚本依赖登录 Shell 环境变量	检查脚本内变量来源	脚本开头 source 配置，或硬编码环境变量
日志报Permission denied	脚本没有执行权限	ls -l script.sh	chmod +x script.sh
脚本文件存在但报找不到	文件属主或权限导致用户无法读取	namei -l检查路径权限	调整属主或权限
脚本执行了但结果数据不对	脚本内用了相对路径	查看脚本内路径写法	全部改为绝对路径
任务里命令输出一堆奇怪符号	Windows 换行符 CRLF	file script.sh	dos2unix转换格式
脚本被拉起但很快退出，无报错	脚本存在语法错误	bash -n script.sh	根据语法错误修正脚本
任务路径正确，但每次都在同一环境失败	命令依赖网络或外部服务不可达	手工执行脚本看报错	在脚本内增加重试和健康检查

7.2 我踩过的几个坑，值得写下来

先说第一个坑：在脚本里用了source加载了一个不存在或权限被改了的配置文件。手动执行时一切正常是因为配置文件它加载了；但 cron 环境偶尔会因为路径解析不同、或者当前用户权限问题，根本 load 不进来，然后脚本里的变量就全是空的。你看到的“现象”可能是备份文件生成了但内容残缺，不仔细看根本发现不了。后来我在脚本最开始加了配置文件存在性检查和关键变量的空值检查，才彻底止住这类问题。具体写法是：

if [ ! -f "$CONFIG_FILE" ]; then echo "config missing" >> /var/log/task.log exit 1 fi

第二个坑：日志轮转。曾经有个任务每天凌晨跑，输出重定向写到了/tmp/task.log。这个文件越来越大，某天因为磁盘满了导致任务完全起不来。排查思路完全被“任务不执行”这个表象带偏，后来才发现/tmp挂载的目录被日志胀满。从那以后，我所有脚本的输出日志都会设置 maxsize 和保留份数。

第三个坑：在一个多用户服务器上，用 root 的 crontab 执行了一个写~/logs/的脚本，但脚本里~被展开成了 root 的家目录，而实际业务用户的数据在另一个用户的目录。看起来任务执行了，但生成的文件去了完全错误的地方。这类问题反复出现，因为它不报错，只是结果不符合预期。所以我现在领域里都有一个共识：脚本里禁用~和相对路径，所有关键目录用变量或绝对路径显式定义。

第四个坑：容器里的 cron 和托管 cron 服务的宿主机之间的时区不一致，导致任务执行时间在容器里看起来是对的、在外面看就是错的。只要日志里时间戳对不上，第一反应就去查时区和时间源，用date && timedatectl一起看，省得自己胡乱猜。

7.3 最后几条独门建议

第一，所有定时任务脚本的第一行，我推荐写成这样：

#!/bin/bash export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

这两行能解决大部分环境变量引发的灵异问题。别嫌啰嗦，这算是最便宜的保险。

第二，定时任务执行时间设计时，错峰很重要。很多服务器上有多个任务，不要让所有任务都挤在 0 点整执行，这不仅可能造成 IO 波峰、数据库连接数瞬间拉高，还可能因为任务互相争抢资源而超时失败。加个随机偏移是很简单的做法，比如：

23 1 * * * /root/scripts/backup.sh

而不是固定0 1 * * *，能有效降低资源争抢概率。

第三，脚本里涉及文件锁的场景，建议用 flock 防止任务重叠执行。比如某备份任务上一次还没跑完，下一次又开始了，两个进程同时操作同一批文件，大概率出问题。flock 的使用非常简单：

#!/bin/bash exec 9>/var/lock/task.lock flock -n 9 || exit 1 # 这里是任务主体

有了锁，任务重叠时会直接退出，避免连锁反应。

第四，强烈建议对定时任务本身做监控。哪怕只是写个简单的健康检查：每个任务执行完往某个状态目录写一个时间戳文件，另一个监控任务如果发现某个任务超过 48 小时没更新，就触发告警。这种做法成本不高，但能把“定时任务是否正常执行”从玄学变成可观测的指标。

8. 写在最后：定期给定时任务做一次“体检”

定时任务这东西，平时存在感很低，但它一出问题往往就是数据没备份、报表没生成、告警没发出这类严重后果。每次排查完，我都会顺手做三件事：把脚本里所有路径和环境变量固定下来；写清任务说明和负责人；把这次的问题和解决方式记录到项目文档里。至少过了半个月、三个月后，再有人问起同类问题，不用从头查起。

我个人还有一个习惯，每隔一段时间检查一次 crontab -l 里所有的任务，把没用的注释或删除，把执行频率不合理或重叠严重的任务重新排布一下。很多定时任务“卡死”“丢失”的问题，其实不是设备故障，就是任务列表太乱，互相抢占资源或者日志把磁盘写满了。定时清理这些看不见的负担，比你想的重要得多。

如果你现在正被某个“明明写了却不执行”的任务搞得头疼，我建议你先冷静下来，按文章里的顺序一步步排查：先确认服务和日志，再给任务加输出重定向，然后检查脚本权限、路径、环境变量。八成以上的问题，会在这个流程里当场现出原形。剩下的两成，靠set -x和env -i基本也能锁死范围。实在没辙，就把现象、日志、脚本三者整理清楚，找有经验的老手看，也远比自己瞎猜要快得多。