1. 为什么根目录爆满总在最要命的时候发生Linux虚拟机根目录空间告急不是故障是系统在用最直白的方式喊“救命”。我见过太多次某次例行更新后服务突然502登录一看df -h输出里/那一行红得刺眼也遇到过CI流水线莫名卡死排查半天发现是/var/lib/docker把根分区塞满了还有更隐蔽的——日志轮转失效/var/log/journal悄无声息吃掉30GB直到磁盘IO飙升到99%才被监控告警揪出来。这些都不是偶然而是Linux文件系统设计逻辑与运维习惯碰撞出的必然结果。根目录/在Linux里是个“兜底容器”它不挑食内核模块、系统配置、临时文件、日志、包管理缓存、甚至Docker镜像层只要没明确挂载到其他分区全往这儿堆。虚拟机环境更甚——物理机上你可能给/var单独分个大区但虚拟机模板往往就一个/分区初始配个20GB图省事结果跑半年就见红。这不是容量规划失误而是对Linux“一切皆文件”哲学的误读我们总以为目录是逻辑隔离的实际硬盘上它们共享同一块inode和block池。/tmp占满和/usr/bin占满对磁盘空间的杀伤力完全等价。关键词里虽未明写但所有根目录满的问题都绕不开三个核心矛盾日志膨胀与轮转失效的博弈、包管理缓存与清理机制的脱节、容器存储与宿主机分区的耦合。比如apt在Debian系会把下载的.deb包全留在/var/cache/apt/archives/默认不自动清理yum/dnf在RHEL系同理/var/cache/yum能轻松囤积数GB旧包而Docker的overlay2驱动更是个黑洞——镜像层、容器层、卷数据全挤在/var/lib/docker下且docker system prune默认不碰正在运行的容器层。这些不是bug是设计取舍系统优先保证功能完整把空间管理权交给你。可现实是多数人只在报警时才打开终端此时rm -rf已成高危操作。提示别信“du -sh * | sort -hr就能定位元凶”的说法。这个命令在根目录下执行极可能因权限不足漏掉关键路径如/proc、/sys下的虚拟文件更糟的是它无法识别硬链接重复计数——同一个文件被多个进程引用时du会把它算多次导致总量虚高。真正的根因分析必须结合df与ncdu双视角。我试过最极端的案例一台生产虚拟机根目录使用率98%du -sh /却只报出12GB。差额那8GB去哪了最后用lsof L1揪出被删除但进程仍持有的大日志文件——这是Linux文件系统的经典陷阱文件被rm后只要还有进程打开着它的fd磁盘空间就不会释放。这种“幽灵占用”在Java应用频繁打日志、Nginx未重载配置的场景下高频出现。所以解决根目录满本质是三步走先止血快速释放空间再诊断精准定位真凶最后筑坝建立长效防控。接下来就拆解这三步里每个动作背后的原理、风险和实操细节。2. 止血操作哪些命令能立刻腾出空间哪些是自毁式操作当df -h显示/使用率超过95%第一反应不是查原因而是保服务。此时每秒都在产生新日志、新临时文件必须用最短路径释放空间。但这里有个致命误区很多人直接rm -rf /var/log/*结果清空了/var/log/syslog却忘了/var/log/journal或者删了Nginx日志却让rsyslog服务因找不到日志文件而崩溃。止血不是暴力清除而是精准卸载压力点。以下是我验证过最稳妥的五类操作按安全等级排序2.1 安全级释放已删除但被进程占用的空间这是最常被忽略的“隐形炸弹”。执行lsof L1需安装lsof包输出类似COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME java 1234 app 12w REG 253,0 0t0 1234567 /var/log/app.log (deleted) nginx 567 root 10w REG 253,0 0t0 7654321 /var/log/nginx/access.log (deleted)括号里的(deleted)就是关键信号。此时执行kill -USR1 PID对Nginx或重启对应服务对Java应用进程会重新打开日志文件原被删除的文件句柄自动关闭空间立即释放。注意kill -USR1是Nginx平滑重载日志的信号不会中断请求而Java应用通常需systemctl restart app。切记不要kill -9这会导致进程异常退出可能丢失未刷盘的数据。2.2 可控级清理包管理器缓存apt cleanDebian/Ubuntu和dnf clean allRHEL/CentOS 8是安全底线。它们只删除/var/cache/apt/archives/或/var/cache/dnf/下的已安装包副本不影响系统任何功能。但要注意apt autoremove --purge的陷阱它会卸载“不再被依赖的包”可能连带删掉你手动装的工具如htop、vim-enhanced。我建议改用apt autoremove --purge -s加-s模拟执行先看它打算删什么确认无误再执行。对于yumRHEL 7yum clean all足够但yum autoremove同样需谨慎。2.3 警惕级压缩或轮转大日志文件/var/log/下动辄GB级的日志是重灾区。直接rm风险高首选logrotate强制轮转# 手动触发logrotate处理所有配置 logrotate -f /etc/logrotate.conf # 或针对单个服务如nginx logrotate -f /etc/logrotate.d/nginx这会按配置将access.log重命名为access.log.1并创建新空文件。若logrotate未配置可用gzip压缩旧日志# 压缩3天前的日志保留原始时间戳 find /var/log -name *.log -mtime 3 -exec gzip {} \;绝对禁止echo /var/log/syslog这类清空操作这会破坏日志文件的inode结构导致rsyslog服务无法追加写入后续日志全部丢失。2.4 高危级Docker存储清理仅限确认无重要容器docker system prune -a --volumes是终极清道夫但它会删除所有停止的容器、所有 dangling 镜像、所有构建缓存、所有未使用的卷。执行前必须确认docker ps -a检查是否有需保留的停止容器如数据库备份容器docker images -f danglingtrue确认dangling镜像是无用的中间层docker volume ls核对卷列表避免误删/var/lib/docker/volumes/下的业务数据卷更安全的做法是定向清理# 只删悬空镜像节省空间最显著 docker image prune -f # 只删未被任何容器引用的卷需确认卷名 docker volume rm $(docker volume ls -qf danglingtrue)2.5 自毁级绝对禁止的操作清单rm -rf /tmp/*可能删掉X11 socket、systemd私有目录导致GUI或服务异常rm -rf /var/lib/dpkg/info/破坏dpkg数据库后续apt操作全失败rm -rf /usr/src/删掉内核源码影响后续模块编译dd if/dev/zero of/bigfile bs1M看似“占位测试”实则可能触发OOM Killer干掉关键进程注意所有rm操作前务必用ls -lh确认目标路径内容。曾有同事rm -rf /var/log/journal/*误输为rm -rf /var/log/journal/少了个*结果整个journal目录被删系统日志功能永久失效只能重装。3. 诊断根因用ncdu和find穿透表象找真凶止血只是应急根因诊断才是治本。du -sh *在根目录下基本失效——权限限制让它跳过/proc、/sys等关键路径且无法处理硬链接。我坚持用ncduNCurses Disk Usage作为主力诊断工具它能实时扫描、交互式钻取、智能去重比du精准十倍。安装与基础用法如下# Ubuntu/Debian apt update apt install -y ncdu # RHEL/CentOS dnf install -y ncdu # 扫描根目录需root权限否则跳过受限目录 ncdu -x -r /-x参数确保不跨文件系统避免扫到/home等独立挂载点-r表示递归。启动后界面类似下图文字描述10.2 GiB [##########] /var 5.1 GiB [##### ] /var/lib 3.8 GiB [#### ] /var/lib/docker 1.2 GiB [# ] /var/log 0.8 GiB [ ] /usr 0.5 GiB [ ] /opt用方向键选中/var/lib/docker按Enter钻入再选overlay2就能看到具体哪个镜像层或容器ID占满空间。ncdu的杀手锏是键标记目录、!键执行shell命令如du -sh * | sort -hr | head -10这比反复敲命令高效得多。但ncdu也有盲区它扫描的是当前文件系统快照对“已删除但未释放”的文件无能为力。这时必须祭出lsof组合拳# 查看所有被进程打开的大文件100MB lsof L1 -s | awk $7 104857600 {print $7/1024/1024 MB, $9} | sort -nr # 按进程聚合被删除文件大小 lsof L1 | awk {sum[$1]$7} END {for (i in sum) print sum[i]/1024/1024 MB, i} | sort -nr输出类似2.3GB java 1.8GB nginx 0.5GB mysqld这直接告诉你该优先处理哪个服务。对于日志类问题find命令比ncdu更锋利# 查找/var/log下大于100MB的文件 find /var/log -type f -size 100M -ls # 查找7天内修改过且大于50MB的日志定位活跃日志源 find /var/log -type f -mtime -7 -size 50M -ls # 检查journal日志总大小systemd专属 journalctl --disk-usage曾有个案例find发现/var/log/journal/xxxxxx/system.journal单个文件达8GB远超/etc/systemd/journald.conf中SystemMaxUse50M的配置。根因是journald服务未重载配置——改完conf文件必须systemctl restart systemd-journald否则配置不生效。这种细节只有深入find结果才能暴露。提示诊断时务必记录时间戳。用date /root/diagnosis.log开头再把所有命令输出重定向进去。这样下次复盘时你能清晰看到“14:22执行ncdu发现/var/lib/docker占3.8GB14:25执行lsof发现java进程持有2.3GB删除日志”形成完整证据链。4. 筑坝工程从配置层杜绝根目录复发的七种长效方案止血和诊断解决的是当下筑坝工程解决的是未来。根目录满不是偶发事故而是系统配置缺陷的必然结果。我总结出七种经生产环境验证的长效方案覆盖日志、包管理、容器、内核等核心层面每一种都附带具体配置和原理说明。4.1 日志用logrotate和journald双保险logrotate是传统日志的守护神。以Nginx为例/etc/logrotate.d/nginx标准配置/var/log/nginx/*.log { daily missingok rotate 30 compress delaycompress notifempty create 0644 www-data www-data sharedscripts postrotate if [ -f /var/run/nginx.pid ]; then kill -USR1 cat /var/run/nginx.pid fi endscript }关键参数解读rotate 30保留30个归档避免无限堆积compressdelaycompress压缩旧日志但不压缩最新轮转的*.log.1保证postrotate能顺利重载sharedscriptspostrotate确保所有匹配文件轮转完成后只执行一次重载避免Nginx被反复重启对于systemd日志/etc/systemd/journald.conf必须调整[Journal] # 限制日志总大小推荐值1G SystemMaxUse1G # 限制单个日志文件大小推荐值100M SystemMaxFileSize100M # 启用日志压缩节省50%空间 Compressyes # 仅保留最近30天日志按需调整 MaxRetentionSec30day修改后必执行systemctl restart systemd-journald。注意SystemMaxUse不是硬上限journald会在达到80%时开始自动清理最老日志所以设1G实际可能用到800MB。4.2 包管理自动化清理策略Debian/Ubuntu系在/etc/apt/apt.conf.d/下创建99auto-clean// 自动清理已安装包的.deb缓存 APT::Clean-Installed:: true; // 卸载无用依赖时自动purge配置文件 APT::Get::AutomaticRemove:: true; // 每次apt upgrade后自动清理 DPkg::Post-Invoke {/usr/bin/apt autoremove --purge -y;};RHEL/CentOS系/etc/dnf/automatic.conf启用自动清理[commands] upgrade_type security random_sleep 3600 # 关键启用自动清理 clean_requirements_on_remove true # 删除旧内核保留最新2个 installonly_limit 2然后启用服务systemctl enable --now dnf-automatic.timer。installonly_limit 2是重点RHEL默认保留所有旧内核每次更新都新增500MB半年下来光/boot就能吃掉3GB。4.3 Docker分离存储与设置回收策略虚拟机中Docker应永远不共用根分区。最佳实践是创建独立LV或挂载点lvcreate -L 20G -n docker-vg vg0格式化后挂载到/var/lib/docker修改Docker daemon配置/etc/docker/daemon.json{ data-root: /var/lib/docker, storage-driver: overlay2, log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }max-size和max-file限制每个容器日志不超过30MB10m×3彻底杜绝日志爆炸。重启Dockersystemctl restart docker。4.4 内核禁用不必要的模块与调试/lib/modules/$(uname -r)/目录常被忽略它存放所有内核模块一个完整内核模块包可达300MB。若虚拟机只跑Web服务可精简# 列出所有已加载模块 lsmod | awk {print $1} /tmp/loaded-modules.txt # 生成未加载模块列表需谨慎仅作参考 ls /lib/modules/$(uname -r)/kernel/ | grep -E (drivers|net|sound) | while read dir; do find /lib/modules/$(uname -r)/kernel/$dir -name *.ko | grep -vFf /tmp/loaded-modules.txt done /tmp/unused-modules.txt切勿直接删除模块文件正确做法是/etc/modprobe.d/blacklist.conf中添加# 禁用蓝牙、火线等虚拟机用不到的驱动 blacklist bluetooth blacklist firewire-core然后dracut -f重建initramfs。这比删文件安全且重启后生效。4.5 临时文件接管/tmp生命周期/tmp默认是内存文件系统tmpfs但很多程序无视TMPDIR环境变量硬写到磁盘。在/etc/fstab中强化控制# 将/tmp挂载为独立tmpfs限制大小为2G tmpfs /tmp tmpfs defaults,size2G,mode1777 0 0重启后df -h /tmp显示为tmpfs且/tmp下所有文件在重启后自动消失。mode1777确保sticky bit生效防止用户删除他人文件。4.6 监控用cronmail实现主动预警被动等报警不如主动巡查。在/etc/cron.d/disk-check中添加# 每小时检查一次根目录 0 * * * * root df -h / | awk NR2 {if ($5 85) print ALERT: / is $5 full} | mail -s Disk Alert adminexample.com更进阶的方案是用inotifywait监听/var/log/变化当日志增长速率超阈值时触发告警。这需要额外安装inotify-tools但能提前2小时预知日志风暴。4.7 备份用rsync替代cp规避硬链接陷阱运维中常需备份/etc或/var/www但cp -r会复制所有硬链接为独立文件导致空间翻倍。正确姿势是# 用rsync保持硬链接关系 rsync -avH --delete /etc/ /backup/etc/ # -H参数保留硬链接-a归档模式-v详细输出--delete同步删除rsync -H确保备份目录中/etc/hosts和/etc/hostname的硬链接关系不变避免备份本身成为空间杀手。5. 实战复盘一次从告警到根治的完整闭环去年处理过一台持续告警的CI虚拟机整个过程堪称根目录治理的教科书案例。我把完整复盘拆解为时间线展示每个决策背后的权衡。T0分钟告警触发Zabbix发出/使用率97%告警。我SSH登录后第一件事不是df -h而是uptime看系统负载——load average: 12.34, 8.76, 5.43说明IO已严重阻塞。此时du扫描会加剧负载果断跳过直奔lsof L1。输出显示java进程持有/var/log/ci-build.logdeleted达4.2GB。执行systemctl restart ci-builder空间瞬间释放2.1GB因部分日志已刷盘df -h回落至89%。T15分钟初步诊断负载下降后运行ncdu -x -r /。/var/lib/docker占比最高3.8GB但钻入发现overlay2下大量diff目录du -sh */diff | sort -hr | head -5显示前5个均超300MB。docker ps -a查到3个已停止的构建容器docker inspect id确认它们未被prune清理。执行docker container prune -f释放1.9GB。T45分钟深度溯源ncdu指向/var/log/journal占1.5GB但journalctl --disk-usage只报800MB。用find /var/log/journal -type f -size 100M发现systemxxx.service.journal文件达1.2GB。检查/etc/systemd/journald.confSystemMaxUse为空即无限制。修改为SystemMaxUse500Msystemctl restart systemd-journald。重启后journalctl --disk-usage稳定在450MB。T2小时长效加固部署七项筑坝措施在/etc/logrotate.d/ci-builder添加日志轮转daily, 7 copies, compresssystemctl enable dnf-automatic.timerRHEL 8/etc/fstab中为/tmp添加tmpfs挂载crontab -e加入每小时磁盘检查脚本docker info | grep Root Dir确认Docker存储仍在根分区计划下周迁移至独立LVT1周效果验证监控显示/使用率稳定在45%-55%区间峰值未超60%。最关键的是lsof L1输出为空ncdu扫描/var/lib/docker降至800MB。这证明问题已从“救火”转向“防火”。这次复盘教会我最重要的一课根目录满不是单一故障而是多个配置缺陷的并发爆发。解决它不能靠一个命令而要像外科手术一样逐层剥离表象直击配置根源。那些看似“多此一举”的logrotate配置、journald.conf调优、tmpfs挂载平时静默无声危机时就是你的护城河。最后分享一个小技巧在所有虚拟机初始化脚本中加入echo ROOT_DISK_CHECK$(df -h / | awk NR2 {print \$5} | sed s/%//) /root/init-report.log。这行代码会在系统启动时记录根目录初始使用率。半年后对比你一眼就能看出是哪个服务悄悄吃掉了空间——因为健康的虚拟机这个数字半年内波动不应超过5%。
