Linux cron 定时任务不执行？常见原因与排查方法

前言

在 Linux 服务器上，cron 经常被用来执行定时备份、清理临时文件、运行脚本等任务。

不过，有时脚本在终端里手动执行完全正常，配置到 crontab 后却没有反应。这种情况不一定是脚本本身有问题，也可能与执行环境、文件权限、系统时区或者日志处理有关。

下面以 Ubuntu、Debian 常见的 cron 服务为例，整理一套比较实用的排查方法。

一、先检查 cron 服务是否运行

首先执行：

systemctl status cron

如果显示 active (running)，说明 cron 服务正在运行。

如果服务没有启动，可以根据实际情况执行：

sudo systemctl start cron
sudo systemctl enable cron

需要注意，不同发行版可能使用不同的任务调度实现和服务名称，不能一概而论。如果提示找不到 cron 服务，应先检查系统是否安装了对应的软件包。

二、检查 crontab 时间表达式

查看当前用户的定时任务：

crontab -l

编辑当前用户的任务：

crontab -e

最常见的 crontab 格式包含五个时间字段：

分 时 日 月 星期 命令

例如：

0 3 * * * /usr/bin/bash /opt/scripts/backup.sh

表示每天凌晨 3:00 执行一次脚本。

再比如：

*/5 * * * * /usr/bin/date

表示每 5 分钟执行一次 date 命令。

这里还有一个容易忽略的区别：使用 crontab -e 编辑的是当前用户的任务，而 sudo crontab -e 编辑的是 root 用户的任务。两者的执行权限、环境变量和文件访问范围可能完全不同。

此外，用户 crontab 的任务行不需要额外填写用户名，而 /etc/crontab 等系统级配置通常包含用户名字段。

三、检查系统时区

如果任务确实会执行，但时间不符合预期，可以先查看系统时间：

date
timedatectl

重点确认系统时区是否正确。

例如，服务器使用 UTC 时区，而自己按照北京时间填写了凌晨 3 点的任务，就会产生 8 小时的时间偏差。

对于传统 cron 实现，通常应按调度器所使用的时区理解任务时间。部分 cron 实现还支持单独指定任务时区，但具体语法和行为需要以当前实现为准。

如果涉及跨时区的服务器，最好先确认实际调度时区，再配置执行时间，而不是直接修改整台服务器的时区。

四、为什么手动执行正常，cron 却失败？

这是实际使用中比较常见的问题。

原因之一是 cron 的执行环境通常比交互式终端简单。比如终端里可以直接使用某个命令，但 cron 环境中的 PATH 不包含对应目录，就可能出现找不到命令的情况。

解决方式是尽量使用绝对路径，例如：

0 3 * * * /usr/bin/bash /opt/scripts/backup.sh

而不是只写：

0 3 * * * backup.sh

脚本内部如果还依赖其他命令，同样需要检查这些命令的路径。

另外，也不要假设 cron 会自动读取交互式 Shell 的配置文件。通过 .bashrc 设置的环境变量，不一定会出现在定时任务的执行环境中。

如果脚本需要特定的环境变量，可以在任务配置中明确设置，或者通过专门的配置文件加载。

五、使用最简单的任务验证

如果不确定 cron 是否真的执行，可以先创建一条只用于排查的任务。

在当前用户的 crontab 中添加：

* * * * * /usr/bin/date >> "$HOME/cron-test.log" 2>&1

这条任务每分钟执行一次，把日期和时间追加到用户家目录中的 cron-test.log 文件。

等待超过一个执行周期后，查看文件：

cat ~/cron-test.log

如果能看到不断追加的时间记录，说明基本调度流程可以正常工作。

确认测试完成后，记得通过 crontab -e 删除这条测试任务，避免它一直运行。

如果连这条简单任务也没有执行，就应该优先检查 cron 服务、任务配置位置和系统日志，而不是继续修改原来的业务脚本。

六、记录任务输出，方便排查

实际配置中，建议把脚本的标准输出和错误输出保存下来。

例如：

0 3 * * * /usr/bin/bash /opt/scripts/backup.sh >> "$HOME/backup.log" 2>&1

其中：

• >> 表示追加输出，不覆盖之前的内容。
• 2>&1 表示将标准错误合并到标准输出。
• backup.log 用于保存执行过程中的输出信息。

如果脚本执行失败，至少能够查看之前有没有打印错误信息。

不过这种追加日志会不断增长。如果任务长期运行，建议定期轮转日志，避免新的磁盘空间问题。

七、查看 cron 系统日志

对于使用 systemd 管理传统 cron 服务的系统，可以尝试：

sudo journalctl -u cron -n 50 --no-pager

如果系统使用 rsyslog，也可能通过以下命令找到相关记录：

sudo grep CRON /var/log/syslog

不同系统的日志位置可能不一样，不能认为某个日志文件不存在就表示任务没有执行。

同时需要区分两件事：cron 日志能证明调度器尝试启动了任务，但不代表脚本中的所有操作都成功完成。因此最好结合前面设置的脚本输出日志一起判断。

八、几个容易忽略的问题

除了上述情况，还需要注意以下几点：

1. 文件权限：任务执行用户必须有权读取脚本，以及访问脚本所依赖的目录和文件。
2. 工作目录：不要默认 cron 会在脚本所在目录执行。脚本如果使用相对路径，可能会读取错误的文件位置。
3. 特殊字符：在常见 crontab 语法中，命令里的 % 有特殊含义，直接写带 % 的 date 格式可能导致命令被意外拆分。可以转义 %，或者把复杂命令放进独立脚本。
4. 任务重叠：如果每分钟执行一次，但脚本需要三分钟才能完成，就可能有多个实例同时运行。对于备份、同步等任务，应考虑使用 flock 等机制避免重复执行。
5. 错过执行时间：传统 cron 通常不会自动补跑服务器关机期间错过的普通任务。如果有补执行需求，需要考虑 anacron 或 systemd timer 等其他方案。

总结

cron 定时任务没有正常执行时，可以按照以下顺序排查：

1. 检查 cron 服务是否运行。
2. 使用 crontab -l 确认任务是否正确配置。
3. 检查系统时区和时间表达式。
4. 使用绝对路径，确认执行用户和环境变量。
5. 配置输出日志，并使用简单任务验证调度。
6. 最后检查文件权限、工作目录和任务重叠等问题。

相比反复重启 cron 服务，更有效的方法通常是先确认任务有没有被调度，再判断脚本是否执行成功。把这两个环节区分开，排查效率会高很多。