清理/var/log需分三类处理：systemd-journald二进制日志（用journalctl --vacuum-size或修改journald.conf）、logrotate管理的文本日志（检查配置并强制轮转）、隐藏大块头如apt/unattended-upgrades日志（truncate或rm清空），严禁直接rm -rf正在写入的日志文件。
清理 /var/log 占用空间不能靠盲目删除，核心是分清三类日志来源：systemd-journald 二进制日志、logrotate 管理的传统文本日志（如 syslog、auth.log）、以及被忽略的“隐藏大块头”（如 apt、unattended-upgrades）。每类需对应不同策略，否则可能白忙活或引发服务异常。
先定位真正占空间的“大户”
别一上来就删。执行以下命令快速锁定目标：
-
sudo du -sh /var/log/* | sort -hr | head -10—— 查看前 10 大目录/文件 -
journalctl --disk-usage—— 单独看 journald 占了多少（常达 GB 级） -
df -h /var—— 确认/var分区是否真的快满了
重点处理 /var/log/journal（最常见瓶颈）
这是现代 Linux 日志膨胀的头号原因，默认不自动清理。安全操作分两步：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
临时清理：保留最近 500MB 日志 →
sudo journalctl --vacuum-size=500M；或只留 2 周 →sudo journalctl --vacuum-time=2weeks -
永久限制：编辑
/etc/systemd/journald.conf，取消注释并设值：SystemMaxUse=500MMaxRetentionSec=4week
保存后运行sudo systemctl restart systemd-journald
检查并修复 logrotate 是否真在工作
很多 /var/log/*.log 文件（如 syslog、kern.log）本该由 logrotate 自动轮转压缩，但配置失效很常见：
- 调试运行：
sudo logrotate -d /etc/logrotate.conf，看是否报错（比如 “parent directory has insecure permissions”） - 若提示权限问题，修复：
sudo chmod 755 /var/log && sudo chown root:root /var/log - 强制执行一次轮转：
sudo logrotate -f /etc/logrotate.conf - 手动清理已归档但过期的压缩包：
sudo find /var/log -name "*.log.*.gz" -mtime +30 -delete
别漏掉那些“不起眼却很能吃”的隐藏目录
这些地方不走标准 logrotate，容易长期堆积：
-
/var/log/apt/：清空升级记录 →sudo truncate -s 0 /var/log/apt/*.log -
/var/log/unattended-upgrades/：删旧文件 →sudo rm -f /var/log/unattended-upgrades/*.log.* -
/var/log/alternatives.log：基本无用 →sudo rm -f /var/log/alternatives.log - Docker 容器日志（若启用）：需单独配
/etc/logrotate.d/docker，规则中加copytruncate
清空单个大日志文件时务必保 inode
对正在写入的文件（如 /var/log/messages），rm 会制造“已删除但仍在写”的幽灵占用：
- 安全清空命令：
sudo truncate -s 0 /var/log/messages - 等效写法（更轻量）：
sudo > /var/log/messages - 验证效果：
stat /var/log/messages看 Size 是否为 0 - 清理后查幽灵占用：
sudo lsof +L1，若有输出，需重启对应服务（如 rsyslog）
