真正可靠的日志清理方案是用logrotate轮转+过期清理或find+cron精准清理；切勿直接rm日志文件，需避开-mtime陷阱、正确配置logrotate参数、区分journal日志特殊处理，并验证服务写入影响。
直接删日志文件是危险操作，真正可靠的方案是用 logrotate 做轮转+过期清理，或用 find + cron 精准清理未纳管日志。别碰正在写入的文件，也别用 rm -rf /var/log/*.log 这类命令。
logrotate 配置必须包含这些关键参数
它不删文件，而是重命名、压缩、再按规则删除旧归档。配置写错会导致轮转失败或保留天数失控。
-
daily或weekly：决定触发频率，不是“每天删一次”，而是“每天检查是否该轮转” -
rotate N：保留 N 个归档（如rotate 7表示最多存 7 份，.1到.7.gz） -
compress+delaycompress：先压缩旧的，但最新一轮（.1）不压，方便紧急排查 -
missingok和notifempty必须加上，否则日志文件临时缺失或为空时，logrotate会报错退出 -
create 644 root root：轮转后重建新文件，权限和属主不能漏，否则某些服务（如 nginx）可能因权限拒绝写入
用 find + cron 清理自定义日志时，-mtime 的坑要避开
-mtime +30 不是“30 天前的文件”，而是“修改时间超过 30×24 小时的文件”，实际可能偏差近 24 小时。对日期敏感的日志（如 app.log.2025-06-01），靠 -mtime 会误删或漏删。
- 先用
find /path -name "*.log" -mtime +30 -print预览，确认结果再加-delete - 若日志名含标准日期（如
error.2025-06-01.log），改用date -d计算阈值 +grep -E匹配更稳妥 - 务必加
-type f，避免find把目录当文件删掉 - 脚本里建议加
2>/dev/null屏蔽权限不足的报错，否则 cron 可能发邮件告警
systemd journal 日志不能用普通方式清理
/var/log/journal/ 下的二进制日志，find 或 rm 直接删会破坏 journal 索引，journalctl 可能报错或无法查询历史。
- 正确方式是调用
journalctl --vacuum-time=2weeks或--vacuum-size=500M - 长期运行的服务器，建议在
/etc/systemd/journald.conf中设SystemMaxUse=500M和MaxRetentionSec=4week，让 journald 自动限流 - 如果已手动删过
/var/log/journal/文件，需运行systemctl restart systemd-journald重建索引，否则journalctl查不到新日志
清理前必须验证是否影响服务写入
有些服务（如 rsyslog、docker daemon）会持续打开日志文件句柄。直接 rm 后它们仍往旧 inode 写，磁盘空间不会释放；而 truncate 或 > 清空内容，服务能继续写入同一文件。
- 查活跃日志进程：
lsof +D /var/log | grep deleted，看是否有“deleted”状态文件还在被写 - 清空而非删除：
sudo truncate -s 0 /var/log/myapp.log或sudo > /var/log/myapp.log - 容器日志路径通常为
/var/lib/docker/containers/*/*-json.log，建议用 docker 自带的log-driver配置大小限制，而不是后期清理
最易被忽略的是：logrotate 配置改完不测试，cron 脚本没加日志记录，journal 清理没重启 journald —— 这三件事不做，自动化就只是看起来在跑。
