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 里写：

Browser Setup (No-Root Linux)

在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

下载

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 却用普通用户身份测试脚本权限——这两处一错，后面全白搭。