Linux 定时任务不执行？cron 排错别只盯表达式

Linux 定时任务不执行？cron 排错别只盯表达式

脚本手动运行成功，放进 cron 却没反应，是服务器运维里非常典型的问题。cron 的环境变量、工作目录、PATH 和交互终端都与手动登录不同。本文按日志、用户、路径、权限和输出五个方向排查。

先确认 cron 服务和记录

systemctl statuscronjournalctl-ucron--sincetodaycrontab-l

Ubuntu 和 Debian 常见服务名是cron，其他发行版可能是crond。还要确认你查看的是正确用户的 crontab，root 和普通用户互不相同。

配置建议和任务边界

cron 不吃配置，但备份压缩、数据库导出、同步上传会吃 CPU、内存和磁盘 I/O。任务多的服务器建议至少 2 核 4G，并把重任务错开，不要全挤在凌晨 3 点。

我会把带备份和巡检任务的服务器放在雨云服务器 rainyun-com的 2 核 4G 机型上，给压缩和同步留出余量。注册填优惠码2026off领 5折，定时任务稳定比极限压低配置更重要。

写成可排错的任务

cron 里使用绝对路径，并把输出写入日志：

SHELL=/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 15 3 * * * /usr/bin/flock -n /tmp/backup.lock /opt/scripts/backup.sh >> /var/log/backup.log 2>&1

flock可以避免上一次任务没结束，下一次又启动。脚本开头建议使用set -euo pipefail，并明确cd到需要的目录。

五个高频原因

1. 脚本没有执行权限或 shebang 写错。
2. 使用相对路径，cron 找不到文件。
3. 依赖的环境变量只存在于登录 shell。
4. 命令需要交互输入或解锁密钥。
5. 任务确实运行了，但输出和错误被丢弃。

先用目标用户执行：

sudo-udeploy /opt/scripts/backup.sh

这样比用 root 手动跑更接近 cron 的真实环境。

验证闭环

临时把执行时间改到两分钟后，观察日志、输出文件和远端备份是否同时变化。测试完成后改回正式时间，不要只看日志里出现“started”。

总结

cron 不执行，往往不是表达式错，而是用户、路径、环境和权限不同。绝对路径、输出日志、任务锁和真实用户测试能解决大多数问题。

需要长期跑备份与自动化任务时，雨云服务器 rainyun-com这类稳定在线的云主机更适合做执行节点，注册填优惠码2026off领 5折。把任务日志保留下来，后续维护会轻松很多。