脚本不生效主因是执行环境或权限问题：find匹配不到日志因归档名不符需按实际后缀调整-name；cron中path和路径失效需用绝对路径并显式声明shell；权限不足或文件被占用会导致删不掉或空间不释放，应先-print测试再-delete。
脚本不生效，大概率不是逻辑错，而是执行环境或权限没对上。直接改完就跑，往往卡在看不见的地方。
find 命令匹配不到日志文件
常见现象是脚本里写了 find /var/log -name "*.log" -mtime +7 -delete，但实际一个文件都没删。原因通常是日志轮转后文件名变了——比如 nginx/error.log.1、tomcat/catalina.out.2026-09-01.gz，而 *.log 根本匹配不到这些归档名。
- 先手动确认真实日志格式：进目标目录执行
ls -1 | head -5，看后缀和命名规律 - 按实际格式调整
-name参数，例如：-name "error.log.*"、-name "*.log.*"、-name "server.*.log" - 加
-print测试匹配结果，别一上来就-delete：find /var/log -name "error.log.*" -mtime +7 -print - 注意
gzip压缩日志（如.log.gz）也要单独写一条规则，find默认不识别压缩包内部时间
脚本被 cron 执行时路径/环境变量失效
你在终端里手动运行脚本一切正常，但加到 crontab 就没反应。这是因为 cron 启动的 shell 是极简环境：$PATH 通常只有 /usr/bin:/bin，很多命令（比如 date 的某些参数、awk 扩展语法）可能不可用，~ 或 $HOME 也不一定指向预期位置。
- 脚本开头显式声明
#!/bin/bash，并用绝对路径调用关键命令，例如：/usr/bin/find、/bin/date - 不要依赖
cd ~或cd ..，所有路径用绝对路径，比如/var/log/nginx/ - 在 crontab 条目里重定向输出，方便排查：
0 2 * * * /opt/scripts/clean-logs.sh >> /var/log/clean-logs.log 2>&1 - 测试前先模拟 cron 环境：
env -i PATH=/usr/bin:/bin /bin/bash -c 'your_script.sh'
权限不足或文件被进程占用
脚本执行了，但提示 Permission denied 或删完空间没释放，说明要么当前用户没权限删，要么文件虽被删，但进程还开着句柄没关。
- 检查目标目录权限：
ls -ld /var/log/tomcat/，确保运行脚本的用户（如root或tomcat）有读+执行（rx）权限，否则find进不去子目录 - 确认是否误删了正在写的实时日志（如
catalina.out），这类文件删了进程还在往旧 inode 写，磁盘空间不会释放；应优先轮转或截断，而非删除 - 删完仍不释放空间？立即查：
lsof +L1 /var/log，看是否有“已删除但未释放”的文件，对应进程需重启或kill -HUP - 避免用
rm -rf直接删整个日志目录，Web 服务或 Java 应用可能因目录不存在而报错甚至拒绝启动
真正麻烦的从来不是脚本写得够不够短，而是你没看见它在哪一步悄悄跳过了条件判断，或者压根没拿到该有的权限。每次改完，先用 -print 看匹配结果，再加 -delete，比反复试错快得多。
