Linux中如何详细配置crontab实现脚本定时执行？
- 内容介绍
- 文章标签
- 相关推荐
本文共计906个文字，预计阅读时间需要4分钟。
plaintextCrontab+命令可以自动运行，不等同于你的脚本按预定时间执行。绝大多数失败不是语法错误，而是环境、权限、路径这三处出现问题。
crontab -e 编辑后不生效？先确认 cron 服务在 running
很多用户改完 crontab -e 就等执行，结果脚本纹丝不动——根本原因是 crond（或 cron）压根没在运行。
- Debian/Ubuntu 系统用
systemctl status cron；CentOS/RHEL 用systemctl status crond - 若显示
inactive (dead)，执行sudo systemctl start cron（或crond） - 别忘了加开机自启：
sudo systemctl enable cron - 改完配置不用重启服务，
crond每分钟自动 reload/var/spool/cron/下的文件
脚本在终端能跑，crontab 里却失败？十有八九是环境变量问题
crond 启动时用的是极简 shell 环境，$PATH 通常只有 /usr/bin:/bin，不会加载你的 ~/.bashrc 或 /etc/profile。
- 在 crontab 条目开头显式声明环境：
0 2 * * * export PATH=/usr/local/bin:/usr/bin:/bin; /home/user/script.sh - 更稳妥的做法：所有命令写绝对路径，比如用
/usr/bin/python3而非python3，用/bin/echo而非echo - 如果脚本依赖 virtualenv，必须在命令中激活：
0 3 * * * /bin/bash -c 'source /path/to/venv/bin/activate && python /path/to/script.py'
/etc/crontab 和 crontab -e 的关键区别在哪
二者格式不同，混用会直接导致任务静默失败。
-
crontab -e编辑的是用户级任务，格式为：分 时 日 月 周 命令绝对路径（共 6 字段） -
/etc/crontab是系统级配置，**必须包含用户名字段**，格式为：分 时 日 月 周 用户名 命令绝对路径（7 字段） -
/etc/cron.d/下的文件也要求 7 字段格式，且文件名不能带点（如mytask可以，mytask.conf会被忽略） - 误把 6 字段条目粘进
/etc/crontab，cron 会跳过整行，/var/log/syslog里可能只有一句bad hour这类模糊提示
如何快速验证 crontab 是否真在执行
别靠“等日志”或“看文件生成”，容易误判。用最直白、可立即观测的方式验证：
- 写个一分钟触发的测试条目：
* * * * * /bin/date >> /tmp/cron-test.log 2>&1 - 等 60 秒后
tail -f /tmp/cron-test.log，看到时间戳就说明 cron 在工作 - 再把你的脚本替进去，同时重定向输出：
* * * * * /path/to/your.sh >> /tmp/your.log 2>&1 - 检查
/tmp/your.log内容，错误信息比盲猜靠谱得多 - 顺手查系统日志：
grep CRON /var/log/syslog（Ubuntu/Debian）或grep CRON /var/log/messages（RHEL/CentOS）
真正卡住人的，从来不是时间表达式怎么写，而是 cron 启动了没、PATH 对不对、脚本有没有 x 权限、输出有没有被吞掉。每次加新任务前，先跑通这个一分钟测试，省下大把排查时间。
本文共计906个文字，预计阅读时间需要4分钟。
plaintextCrontab+命令可以自动运行，不等同于你的脚本按预定时间执行。绝大多数失败不是语法错误，而是环境、权限、路径这三处出现问题。
crontab -e 编辑后不生效？先确认 cron 服务在 running
很多用户改完 crontab -e 就等执行，结果脚本纹丝不动——根本原因是 crond（或 cron）压根没在运行。
- Debian/Ubuntu 系统用
systemctl status cron；CentOS/RHEL 用systemctl status crond - 若显示
inactive (dead)，执行sudo systemctl start cron（或crond） - 别忘了加开机自启：
sudo systemctl enable cron - 改完配置不用重启服务，
crond每分钟自动 reload/var/spool/cron/下的文件
脚本在终端能跑，crontab 里却失败？十有八九是环境变量问题
crond 启动时用的是极简 shell 环境，$PATH 通常只有 /usr/bin:/bin，不会加载你的 ~/.bashrc 或 /etc/profile。
- 在 crontab 条目开头显式声明环境：
0 2 * * * export PATH=/usr/local/bin:/usr/bin:/bin; /home/user/script.sh - 更稳妥的做法：所有命令写绝对路径，比如用
/usr/bin/python3而非python3，用/bin/echo而非echo - 如果脚本依赖 virtualenv，必须在命令中激活：
0 3 * * * /bin/bash -c 'source /path/to/venv/bin/activate && python /path/to/script.py'
/etc/crontab 和 crontab -e 的关键区别在哪
二者格式不同，混用会直接导致任务静默失败。
-
crontab -e编辑的是用户级任务，格式为：分 时 日 月 周 命令绝对路径（共 6 字段） -
/etc/crontab是系统级配置，**必须包含用户名字段**，格式为：分 时 日 月 周 用户名 命令绝对路径（7 字段） -
/etc/cron.d/下的文件也要求 7 字段格式，且文件名不能带点（如mytask可以，mytask.conf会被忽略） - 误把 6 字段条目粘进
/etc/crontab，cron 会跳过整行，/var/log/syslog里可能只有一句bad hour这类模糊提示
如何快速验证 crontab 是否真在执行
别靠“等日志”或“看文件生成”，容易误判。用最直白、可立即观测的方式验证：
- 写个一分钟触发的测试条目：
* * * * * /bin/date >> /tmp/cron-test.log 2>&1 - 等 60 秒后
tail -f /tmp/cron-test.log，看到时间戳就说明 cron 在工作 - 再把你的脚本替进去，同时重定向输出：
* * * * * /path/to/your.sh >> /tmp/your.log 2>&1 - 检查
/tmp/your.log内容，错误信息比盲猜靠谱得多 - 顺手查系统日志：
grep CRON /var/log/syslog（Ubuntu/Debian）或grep CRON /var/log/messages（RHEL/CentOS）
真正卡住人的，从来不是时间表达式怎么写，而是 cron 启动了没、PATH 对不对、脚本有没有 x 权限、输出有没有被吞掉。每次加新任务前，先跑通这个一分钟测试，省下大把排查时间。