crontab -e 编辑后不生效，首要检查cron服务状态及用户权限；需用systemctl status cron/crond确认运行，crontab -l验证内容，使用绝对路径、显式解释器、重定向日志，并转义%等特殊字符。

直接用 crontab -e 就能加，但多数失败不是因为不会写，而是环境、路径、权限这三样没对齐。

crontab -e 编辑后不生效？先检查 cron 服务是否在跑

crontab 文件改了，但任务完全没触发，大概率是后台的 cron 进程根本没运行。

• Debian/Ubuntu 系统执行：systemctl status cron；CentOS/RHEL 执行：systemctl status crond
• 如果显示 inactive (dead)，必须手动启动：sudo systemctl start cron（或 crond）
• 顺手加上开机自启：sudo systemctl enable cron
• 注意：改完 crontab -e 不需要重启 cron 服务，它每分钟自动 reload 一次

为什么脚本在终端能跑，放进 crontab 就失败？

crontab 的执行环境和你登录终端完全不同：没有你的 PATH、没加载 ~/.bashrc、工作目录默认是用户家目录，且不继承 shell 变量。

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• 所有命令尽量用绝对路径：/usr/bin/python3 而不是 python3，/bin/date 而不是 date
• 脚本第一行加 #!/bin/bash，并在 crontab 中显式调用：/bin/bash /home/user/script.sh
• 在 crontab 行末加日志重定向，快速定位问题：0 2 * * * /bin/bash /home/user/backup.sh >> /tmp/backup.log 2>&1
• 如果脚本依赖当前目录（比如读配置文件），在脚本开头加 cd /home/user 显式切换

/etc/crontab 和 /etc/cron.d/ 下的任务总不执行？看用户名字段和权限

系统级 crontab（/etc/crontab）和 /etc/cron.d/ 下的文件，格式比用户级多一列 —— 第六列必须是**执行用户**，漏写或写错就静默失败。

• /etc/crontab 格式是：分 时 日 月 周 用户名 命令，例如：30 3 * * * root /usr/bin/find /tmp -mmin +60 -delete
• /etc/cron.d/myjob 同样要带用户名字段，且文件权限必须是 644：sudo chmod 644 /etc/cron.d/myjob
• 文件名不能带点或破折号（如 my-job 或 task.py），cron 会直接跳过——只认字母、数字、下划线
• 修改后不用手动 reload，cron 每分钟扫描这些目录，但建议等 1–2 分钟再验证

测试 crontab 时间表达式是否写对？别靠等，用工具验证

时间字段写错是最隐蔽的问题，比如把周日写成 7（部分系统只认 0）、把 */5 误写成 /*5，都会导致整行被忽略。

• 用在线工具验证，比如 crontab.guru，输入你的表达式，看它解析出的时间对不对
• 本地调试可临时设成每分钟执行：* * * * * /bin/date >> /tmp/test-cron.log，确认能写入再调回真实时间
• 注意：0 0 * * * 是每天 00:00（午夜），不是中午；0 12 * * * 才是每天中午 12:00
• 周几和日期不要同时设为具体值（比如 0 2 15 * 3），cron 会要求「满足任一条件即执行」，容易误触发

真正卡住人的往往不是语法，而是 cron 的静默行为：不报错、不提示、不写日志（除非你主动重定向）。每次加完任务，务必立刻查日志、看输出、确认权限，而不是等到第二天发现备份没做。