必须用 sudo crontab -e 编辑 root 任务，因普通用户无权删除 /var/log 等系统目录文件；脚本需指定绝对路径、显式解释器、环境隔离，并重定向日志，否则静默失败。
crontab 必须用 sudo crontab -e 编辑 root 任务
普通用户 crontab 没法删 /var/log、/tmp 或其他系统目录下的文件，脚本会静默失败。直接运行 crontab -e 编辑的是当前用户任务，而清理系统级文件必须走 sudo crontab -e。
常见错误：在普通用户下写 0 2 * * * /usr/local/bin/clean.sh，结果脚本里 /bin/rm /var/log/nginx/*.log 总是没反应——因为权限不够，rm 返回 Permission denied 但被 cron 丢弃了（没重定向输出）。
- 别在 crontab 行里加
sudo：sudo rm在 cron 下无效，不会弹密码提示，直接卡住或失败 - 所有清理操作必须由 root 权限执行，否则对
/proc/sys/vm/drop_caches、/var/log、/tmp等路径的写/删操作都会失败 - 验证方式：
sudo crontab -l应该能看到你的任务；sudo grep CRON /var/log/syslog（或/var/log/cron）可查执行记录
脚本必须显式声明解释器、绝对路径、环境隔离
cron 默认用 /bin/sh 执行，且 $PATH 极窄（通常只有 /usr/bin:/bin），很多命令如 date -d、python3、jq 都找不到。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 脚本第一行必须是
#!/bin/bash（或#!/usr/bin/env bash），且 crontab 中显式调用：0 2 * * * /bin/bash /usr/local/bin/clean.sh - 所有外部命令优先用绝对路径：
/usr/bin/find、/bin/rm、/usr/bin/date，不能只写find - 测试前先模拟 cron 环境：
env -i /bin/bash --noprofile --norc /usr/local/bin/clean.sh，这能暴露绝大多数路径和变量问题
清理逻辑别依赖文件名日期，要用 -mtime 或 -daystart
靠解析 backup_20240501.tar.gz 里的字符串判断过期，极易出错：文件被 touch 修改时间、命名不规范、时区错位，都会导致该删不删或误删。
- 更可靠的方式是基于文件最后修改时间（即实际备份/写入完成时间）：
/usr/bin/find /backup -type f -name "*.tar.gz" -mtime +7 -delete（删 7 天前修改的文件；注意：-mtime +7= 大于 168 小时，不是“第 7 天当天”） - 加
-daystart让时间计算从当日 00:00 开始，避免因执行时间浮动导致延迟一天：-daystart -mtime +7 - 调试阶段务必先用
-print或-ls替代-delete，确认列出的确实是目标文件 - 限定作用范围：
-maxdepth 1防止递归进子目录误删；-type f明确只处理文件
日志和锁机制不能省，否则失败无声、并发冲突
没有日志，脚本失败你看不到；没有锁，多个定时任务同时跑可能删掉正在写的日志或清空一半的缓存。
- 每行 cron 必须重定向输出：
0 2 * * * /usr/local/bin/clean.sh >> /var/log/clean.log 2>&1，否则错误全丢弃 - 脚本内应加入锁判断，例如：
[ -f /tmp/clean.lock ] && exit 1; touch /tmp/clean.lock; trap 'rm -f /tmp/clean.lock' EXIT - 对
drop_caches类操作，建议前后加内存快照：free -h >> /var/log/clean.log，便于确认是否生效
最常被忽略的是环境隔离和日志重定向——这两点不出问题时一切正常，一出问题就完全无迹可寻。动手前先跑一遍 env -i ... 模拟，再加 >> /var/log/xxx 2>&1，能省掉 90% 的排查时间。
