crontab任务不执行八成因环境问题：默认用/bin/sh（非bash）、PATH极简（/usr/bin:/bin）、工作目录为家目录，须用绝对路径、显式设置环境变量并重定向日志。
crontab 任务写完不执行？八成卡在 PATH、Shell 环境或路径上，不是语法错，而是运行时根本找不到命令或脚本。
crontab -e 编辑后任务不生效的常见原因
直接运行 crontab -e 保存后，任务不会立刻执行——但也不需要重启服务。真正卡住的地方往往不是时间表达式，而是环境差异：
- 默认使用
/bin/sh，不是你的~/.bashrc或zsh，所以别用[[ ]]、source、数组等 bash 特有语法 - PATH 极其精简（通常是
/usr/bin:/bin），python、node、mysqldump这类命令大概率报 “command not found” - 工作目录是用户家目录（
~），脚本里写./data/config.json会失败；必须用绝对路径或先cd /path/to/dir && - 没加日志重定向，stdout/stderr 被丢进邮件队列（如果 mail 服务没配，就彻底消失了）
如何让 Python 脚本在 crontab 中稳定运行
虚拟环境里的 Python 脚本最容易“本地能跑，cron 不动”。不要试图在 crontab 行里写 source venv/bin/activate && python script.py——source 在 /bin/sh 下无效。
正确做法是封装一层 shell 脚本：
#!/bin/bash cd /home/user/myproject source /home/user/myproject/venv/bin/activate python main.py >> /home/user/myproject/cron.log 2>&1
然后确保它可执行：chmod +x /home/user/myproject/run.sh，再在 crontab -e 里写：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
0 3 * * * /home/user/myproject/run.sh
注意：所有路径都用绝对路径；source 前不用 .，因为脚本指定了 #!/bin/bash；日志重定向必须显式加上。
/etc/crontab 和 /etc/cron.d/ 的权限与格式陷阱
系统级定时任务不走 crontab -e，手动编辑时容易踩两个硬性规则：
-
/etc/crontab和/etc/cron.d/下每个文件**必须多一列用户名**，格式是：分 时 日 月 周 用户名 命令；漏掉用户名就会静默忽略整行 - 文件权限必须是
644，属主属组为root:root；带扩展名（如backup.sh）或权限不对（如755）的文件，crond直接跳过不读 - 修改后无需重启服务，但建议执行
sudo systemctl reload cron（Ubuntu/Debian）或sudo systemctl reload crond（CentOS/RHEL）强制重新扫描
怎么快速验证 crontab 是否真在跑
别等“明天凌晨2点”，用短周期+日志+系统日志三重确认：
- 临时改成
*/2 * * * *（每2分钟），配合>>/tmp/cron-test.log 2>&1记录输出 - 实时看 cron 日志：
sudo tail -f /var/log/syslog | grep CRON（Ubuntu/Debian）或sudo tail -f /var/log/cron（CentOS/RHEL） - 检查任务是否被加载：
sudo grep -r "your_script" /var/spool/cron/ /etc/crontab /etc/cron.d/
最常被忽略的是：crond 服务本身没起来，或者你编辑的是 root 的 crontab 却用普通用户身份测试脚本权限——这两处一错，后面全白搭。
