crontab -e 编辑后不生效主因是编辑器未更新文件时间戳或写入失败，需用crontab -l确认真实内容，避免挂起编辑器；cron环境精简，须用绝对路径并显式设置PATH等变量，注意时间格式“分 时 日 月 周”及日/周字段为or关系，排查需结合日志、权限与SElinux/appArmor限制。
crontab -e 编辑后不生效
多数人改完 crontab -e 就以为万事大吉，其实 cron 守护进程不会自动重载用户 crontab 文件——它靠轮询检测 mtime 变化来加载，但某些编辑器（如 nano、vim 用 swap 文件机制）可能不更新文件时间戳，或写入中途失败。
- 用
crontab -l确认内容已真正写入，不是编辑器缓存里的“假保存” - 避免在编辑时 Ctrl+Z 挂起、直接 kill 编辑器进程，这会导致临时文件残留、crontab 文件被截断
- 修改后可手动触发检查：
sudo systemctl reload cron（debian/ubuntu）或sudo systemctl reload crond（RHEL/centos），但更稳妥的是等 1 分钟后看/var/log/syslog或/var/log/cron是否有解析错误
脚本在 cron 中执行失败，但在终端能跑通
根本原因是 cron 环境极度精简：PATH 通常只有 /usr/bin:/bin，HOME、SHELL、USER 等变量也未必和登录 shell 一致，且无 tty。
- 所有命令尽量用绝对路径，比如写
/usr/bin/python3而非python3，用/home/user/script.sh而非./script.sh - 在脚本开头显式设置环境：
export PATH="/usr/local/bin:/usr/bin:/bin"，必要时加export HOME="/home/username" - 重定向 stdout/stderr 到文件，方便排查：
* * * * * /path/to/script.sh >> /tmp/script.log 2>&1 - 如果脚本依赖 systemd 用户服务、ssh-agent 或图形会话变量，cron 基本无法继承——得改用
systemd --user timer或在脚本里手动启动依赖
时间格式写错导致任务从不触发
crontab 时间字段顺序是「分 时 日 月 周」，和大多数人直觉的「年月日时分」完全相反；且「周」和「日」是 or 关系（任一满足即执行），这点极易引发误触发或漏触发。
-
0 2 * * 1表示“每周一凌晨 2 点”，不是“每月 1 号凌晨 2 点”——后者应写0 2 1 * * - 避免混用日和周字段：
0 2 1 * 1表示“每月 1 号 + 每周一”，只要满足其一就执行，可能导致重复运行 - 注意月份和星期的取值范围：月是 1–12，周是 0–7（0 和 7 都代表周日），但部分 cron 实现（如 Vixie cron）把周日记为 0，而 systemd timer 用的是 1=Mon…7=Sun，不兼容
- 测试时间表达式可用在线工具如 crontab.guru，但别全信——实际行为还取决于 cron daemon 版本（如 anacron、fcron 行为不同）
权限与 SELinux/AppArmor 阻止执行
即使脚本路径、权限、环境都对，Linux 安全模块仍可能静默拦截 cron 调用。典型表现是日志里只显示“CMD (xxx)”但无后续输出，且 strace 会卡在 execve 系统调用。
- 检查 cron 进程是否被限制：
ps auxZ | grep cron，看上下文是否含unconfined或具体策略名 - RHEL/CentOS 上临时放行测试：
sudo setsebool -P cron_can_exec 1；Ubuntu 上检查 AppArmor：sudo aa-status | grep cron，再查/var/log/audit/audit.log有无 avc denied 记录 - 普通用户 crontab 默认禁止执行某些敏感路径（如
/tmp下的脚本），可改用/var/spool/cron/crontabs/直接写系统级任务（需 root 权限）或确保脚本在/home下且权限为 644（不可写组/其他）
cron 的“静默失败”特性让它比 systemd timer 更难调试——它不报错，只跳过。最有效的习惯是：每次加新任务，先设成每分钟执行一次，重定向输出，盯两分钟日志，确认路径、权限、环境三者全部闭环，再调回真实周期。