crontab -e 编辑后不生效，首要检查 cron 服务是否运行及用户权限是否匹配；需用 systemctl status cron/crond 确认状态，用 crontab -l 验证内容，指定绝对路径、显式解释器、重定向日志，并转义 % 等特殊字符。
crontab -e 编辑后不生效？检查用户权限和守护进程状态
直接运行 crontab -e 保存后任务没执行，大概率不是语法问题，而是 cron 服务根本没在运行，或者你编辑的是 root 的 crontab 却想让普通用户脚本运行。Linux 中每个用户有独立的 crontab，crontab -e 默认操作当前用户，root 用户需显式用 sudo crontab -e 才能编辑系统级任务。
确认 cron 是否运行：systemctl status cron（Debian/Ubuntu）或 systemctl status crond（RHEL/CentOS）。若显示 inactive，请先启用：sudo systemctl enable --now cron。
- 普通用户无法写入
/var/spool/cron/目录，所以不能直接改文件，必须用crontab -e - 编辑保存后，cron 不会 reload，但会自动检测文件 mtime 变化——等最多 1 分钟即可生效
- 如果用 vim 编辑，意外退出未保存（比如按了
:q!），crontab 实际没更新，建议保存后加一句crontab -l确认内容
分钟字段写成 */5 就一定能每 5 分钟跑一次？注意路径和环境变量
*/5 * * * * 确实表示每 5 分钟执行一次，但绝大多数失败都出在命令本身：脚本找不到解释器、依赖的命令不在 $PATH、当前工作目录不是你预期的路径。
crond 启动时环境极简，$PATH 通常只有 /usr/bin:/bin，不会包含 /usr/local/bin 或你的 ~/bin。所以不要写 */5 * * * * myscript.sh，而应写绝对路径 + 显式解释器：
*/5 * * * * /bin/bash /home/user/scripts/backup.sh
- 脚本第一行加
#!/bin/bash不够，crond 不读 shebang，必须显式调用解释器 - 脚本内用相对路径（如
./data/log.txt）会失败，因为 cron 的 cwd 是用户 home 目录，且可能不是你测试时的目录 - 需要环境变量（如
HOME、USER）时，在 crontab 开头定义：HOME=/home/user，或在脚本里重新 export
日志没输出？重定向 stdout/stderr 是唯一可靠方式
crond 不把命令输出显示在终端，也不写入系统日志（除非配置了 syslog），默认所有 stdout/stderr 都通过邮件发给任务所属用户——但多数服务器没配本地 mail，结果就是“静默失败”。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
最简单办法是强制重定向到文件：
0 2 * * * /usr/bin/python3 /opt/maintain/clean.py >> /var/log/clean.log 2>&1
-
2>&1必须写在重定向末尾，顺序不能错；> file 2>&1正确，2>&1 > file会丢掉 stderr - 避免用
>>无限追加导致日志过大，可配合logrotate或脚本内判断文件大小 - 临时调试时，加一句
date >> /tmp/debug.log能快速验证 cron 是否真触发了
特殊字符 % 在命令中要转义，否则会被 crond 当作换行符处理
crond 把命令行中第一个未转义的 % 当作 stdin 输入分隔符，后面所有内容都会被当成输入传给命令——这会导致命令截断或参数错乱，而且错误极难排查。
比如你想用 curl 发带时间戳的请求：
# 错误写法（% 被截断）： 0 * * * * curl "https://www.php.cn/link/7ae738bc1140fa060c536fbbf19ab21b +%s)" <h1>正确写法（\% 转义）：</h1><p>0 <em> </em> <em> </em> curl "<a href="https://www.php.cn/link/7ae738bc1140fa060c536fbbf19ab21b">https://www.php.cn/link/7ae738bc1140fa060c536fbbf19ab21b</a> +\%s)"
- 所有 shell 特殊字符在 crontab 中都要小心，但
%是 crond 自己解析的，优先级高于 shell，所以必须转义 - 如果命令含多个
%（如date +\%Y-\%m-\%d），每个都要加反斜杠 - 更稳妥的做法是把复杂命令全写进脚本，crontab 只调用脚本，避开所有 shell 解析干扰
实际用多了就会发现，crontab 本身很稳定，真正花时间的永远是环境一致性、路径假设和静默失败——别信“写完就跑”，每次加新任务，至少留 5 分钟看日志、确认路径、检查权限。
