直接删大日志文件不释放空间，必须用 truncate -s 0 清空；批量清理应选 find + gzip 或 logrotate；systemd-journal 日志须用 journalctl --vacuum-size/Time 清理，不可 rm 或 truncate。
直接删 rm 大日志文件不释放磁盘空间，必须用 truncate -s 0 或重定向清空内容；若要批量处理过期日志，find + gzip 或 logrotate 才是可靠方案。
truncate -s 0 是最安全的实时清空方式
当 /var/log/syslog 或 /var/log/nginx/access.log 膨胀到几 GB，且服务仍在写入时，rm 只是 unlink，磁盘空间不会回收——因为进程还持有文件句柄。此时唯一有效做法是截断内容，保留 inode 和权限。
-
sudo truncate -s 0 /var/log/syslog：立即把文件大小设为 0 字节，nginx、rsyslog 等无需 reload 就能继续写入 - 比
> /var/log/syslog更适合超大文件（实测 >1GB 时更稳定） - 支持非零截断，比如
truncate -s 1M /var/log/app.log保留最后 1MB 用于紧急排查 - 注意权限：目标文件属主需允许当前用户写入，否则报
Operation not permitted
find + -mtime 清理 N 天前的旧日志文件
-mtime +7 不是“7 天前的日志”，而是“修改时间早于 7×24 小时前的文件”，即精确到秒级的时间窗口。误用会导致漏删或误删。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 加
-type f排除目录匹配，避免find报错或误操作 - 用
-name "*.log"或-name "access.log.*"明确限定扩展名，避开journal或syslog.1.gz等已归档文件 - 生产环境务必先试运行：
sudo find /var/log -type f -name "*.log" -mtime +30 -ok rm -f {} \;，每删一个都确认 - 删除后建议补一句
sync，确保文件系统元数据刷盘
logrotate 才是长期管理日志的正确姿势
手动清理是救火，logrotate 是防火。它不依赖定时脚本，而是由系统 cron 每天自动触发，支持轮转、压缩、权限控制、通知服务重载等完整生命周期管理。
- 配置写在
/etc/logrotate.d/nginx或/etc/logrotate.conf，例如： /var/log/nginx/*.log { daily rotate 30 compress delaycompress missingok notifempty create 0644 www-data adm }-
delaycompress很关键：保证最新轮转的access.log.1暂不压缩，方便出问题时快速查看 -
postrotate ... kill -USR1 ... endscript可让 nginx 无缝切换到新日志文件，完全不中断服务
systemd-journal 日志不能用 find 清理
/var/log/journal/ 下的二进制日志不是普通文本文件，find + rm 或 truncate 会损坏结构，导致 journalctl 报 Input/output error。
- 必须用
journalctl --vacuum-size=500M或--vacuum-time=7d安全清理 - 该命令会自动重建索引，只删最老的条目，不影响查询和完整性
- 如果磁盘已满且
journalctl崩溃，先systemctl stop systemd-journald，再手动删/var/log/journal/*/*.journal~（带波浪号的临时损坏文件），再重启服务
真正容易被忽略的是日志路径的多样性：除了 /var/log，还要检查 /var/log/journal（systemd）、/www/wwwlogs（宝塔）、/var/lib/docker/containers/*/（容器日志），它们各自适用的清理机制完全不同——混用命令等于埋雷。
