1. 为什么根目录爆满总在凌晨三点“准时发作”Linux系统里根目录/突然写满不是故障而是系统在用最粗暴的方式喊救命。我第一次遇到这问题是在一个监控告警平台的生产环境凌晨3:17收到钉钉消息“/dev/sda1 usage 99%”紧接着所有日志采集进程开始超时API响应延迟飙升到8秒以上而值班同事正靠在椅子上打盹——这个时间点绝非偶然。根目录爆满的本质是系统级资源耗尽的连锁反应不是磁盘真的被“塞满”了文件而是被大量不可见、不释放、不清理的临时数据占用了inode或block。它和普通用户目录满有本质区别你用df -h看到99%但du -sh /*加起来可能才60GB你删掉几个G的日志df显示空间没变你重启服务空间反而更少了。这些反直觉现象恰恰暴露了Linux底层存储管理的真实逻辑。核心关键词就三个根目录、爆满、实战解决。这不是教科书式的磁盘清理教程而是还原一次真实故障从发现、定位、止血到根治的完整链路。适合两类人一是刚接手线上服务器的运维新人看到df -h报警就慌神不知道该先看哪二是开发同学写的脚本在后台疯狂生成临时文件却浑然不觉。本文不讲抽象原理只说那天我们到底做了什么、为什么这么做、哪些操作踩了坑、哪些判断救了命。真正致命的从来不是“空间不够”而是“空间不够”背后隐藏的时间错配日志轮转配置是按天执行但某次数据库慢查询导致单条日志暴涨200MB临时文件清理脚本设在每天23:00运行可凌晨2:00有个定时任务突然fork出300个子进程每个都往/tmp写缓存甚至内核OOM Killer在内存不足时会把进程core dump直接扔进/var/crash——而这个目录默认就在根分区。所以根目录爆满从来不是单一原因而是多个时间维度上的清理策略集体失效的结果。提示不要一上来就rm -rf /tmp/*。很多服务如systemd、dbus、某些Java应用依赖/tmp下的socket文件或锁文件暴力清空可能导致服务假死或状态错乱。真正的止血动作永远比删除文件多一步验证。2. 定位真相df和du结果对不上时先查inode而非空间那天凌晨3:17df -h显示根分区使用率99%但du -sh /* 2/dev/null | sort -hr | head -10输出的前几项加起来不到45GB。这种“看得见的文件少看不见的空间多”的割裂感是根目录爆满最典型的表征。此时若直接删大文件大概率徒劳无功——因为真正吃掉空间的可能是被进程占用但已删除的文件unlinked but held open或是海量小文件耗尽了inode。2.1 第一现场用df -i揪出inode耗尽的真凶我们立刻执行df -i /输出显示IUse%为98%。这就锁定了方向——不是磁盘块block耗尽而是inode耗尽。inode是Linux文件系统的元数据索引节点每个文件、目录、软链接都占用一个inode。当inode用完即使磁盘还有大量剩余空间系统也无法创建新文件包括日志、临时文件、甚至touch测试文件都会报错No space left on device。为什么inode会先耗尽因为/var/log/journal、/tmp、/var/spool/postfix这类目录天生就是“小文件黑洞”。比如systemd-journald默认将日志按小时切片每小时生成几十个.journal~文件某个Python脚本每秒生成一个/tmp/xxx.pid临时文件却忘记清理邮件队列里堆积了上万封未发送的邮件草稿。这些文件平均大小只有几KB但数量轻松突破百万级瞬间榨干默认分配的inode。2.2 深挖小文件find命令必须带-xdev参数要找出哪个目录在疯狂产卵不能简单用du -sh *因为du统计的是当前可见文件的磁盘占用对已删除但被进程占用的文件无效对硬链接也容易重复计算。我们执行find / -xdev -type f -size 10M -print0 | xargs -0 ls -lhS | head -20这里-xdev是生死线——它强制find不跨文件系统避免误入/proc、/sys等虚拟文件系统这些目录里的“文件”实际是内核接口du会报错find会卡死。结果发现/var/log/journal/xxxxxx/system.journal~单个文件达1.2GB但ls -l显示其硬链接数为0说明它已被journald标记为待归档却因磁盘满无法完成压缩迁移。更关键的是我们用另一条命令扫出了真正的“小文件王”find /var -xdev -type f | cut -d / -f 1-4 | sort | uniq -c | sort -nr | head -10输出第一行是248760 /var/log/journal/123abc这意味着仅/var/log/journal/123abc这一个子目录下就存在近25万个日志文件。而/var/log/journal默认配置不限制单个machine ID下的日志总量只限制总大小SystemMaxUse但这个限制在inode耗尽时根本来不及触发。2.3 验证“幽灵文件”lsof L1直击已删除但被占用的文件df和du对不上还有一个经典原因是文件已被rm删除但仍有进程打开着它的文件描述符fd。这种文件在ls里不可见du不统计但df认为它仍占空间。我们执行lsof L1 | grep /$ | head -10L1参数专门列出link count为0的文件即已删除但被进程持有。结果赫然出现rsyslogd 1234 root 1w REG 8,1 124567890 0 /var/log/syslog (deleted) java 5678 app 23w REG 8,1 987654321 0 /tmp/app_cache.dat (deleted)原来rsyslogd进程还在往已删除的/var/log/syslog写日志它没收到HUP信号重载而Java应用把缓存文件写到/tmp后忘了关闭流导致文件句柄一直挂着。这些“幽灵文件”加起来占了12GB空间du完全看不到df却实打实算进去了。注意lsof L1需要root权限且在高负载服务器上执行可能短暂影响性能。如果lsof命令不存在可用find /proc/*/fd -ls 2/dev/null | grep deleted替代原理相同——遍历所有进程的文件描述符链接。3. 止血三板斧不重启服务的前提下快速释放空间定位清楚后必须立刻止血否则系统可能在5分钟内彻底僵死。我们的操作原则是优先释放inode再释放block优先处理可逆操作最后动核心配置。所有操作都在凌晨3:30前完成全程未重启任何服务。3.1 第一斧安全清空/tmp并重建tmpfs15秒见效/tmp是根目录下最“野”的区域几乎所有服务都默认往这里写临时文件且多数不校验空间。我们检查/tmpdf -i /tmp ls -la /tmp | wc -l发现inode使用率92%文件数超18万。但/tmp的特殊性在于它是唯一一个可以随时清空且不影响服务稳定性的目录只要不删正在被进程使用的文件。我们执行# 先找出哪些文件正被使用避开它们 lsof D /tmp 2/dev/null | awk {print $9} | sort -u /tmp/inuse.list # 清空所有未被使用的文件 find /tmp -mindepth 1 -maxdepth 1 ! -name .* -not -path $(cat /tmp/inuse.list | head -1) -delete 2/dev/null # 确认清理效果 df -h /tmp这一招立竿见影df -i /从98%降到82%。但这是权宜之计。第二天我们永久方案是将/tmp挂载为tmpfs内存文件系统在/etc/fstab中添加tmpfs /tmp tmpfs defaults,size2G,mode1777 0 0这样/tmp不再占用磁盘inode且最大只吃2GB内存超出则自动swap虽不推荐但比填满根目录强。重启后df -h /tmp显示为tmpfs类型df -i /的inode压力直接消失。3.2 第二斧精准收割journal日志3分钟释放8GB/var/log/journal是inode杀手但不能直接rm -rf因为journald服务正实时写入。正确姿势是# 1. 停止journald瞬时操作不影响其他服务 sudo systemctl stop systemd-journald # 2. 归档并压缩旧日志保留最近7天 sudo journalctl --vacuum-time7d # 3. 强制释放被删除但未回收的journal文件 sudo find /var/log/journal -name *.journal~ -delete # 4. 重启journald sudo systemctl start systemd-journaldjournalctl --vacuum-time7d是关键——它不是简单删除而是调用journald内置的归档引擎先将旧日志压缩成.journal~再安全删除原始文件整个过程保证日志完整性。执行后df -i /降到65%df -h /释放8.3GB空间。经验journalctl --disk-usage能精确显示journal占用的磁盘和inode量比du可靠10倍。日常巡检应加入此命令。3.3 第三斧终结“幽灵文件”30秒根治对lsof L1找到的已删除但被占用的文件不能kill进程可能中断业务而是向进程发送信号促使其释放。例如# 让rsyslogd重载配置关闭旧日志句柄 sudo kill -HUP 1234 # 让Java应用触发GC并关闭缓存流需应用支持JMX或提供shutdown endpoint curl -X POST http://localhost:8080/actuator/shutdown如果进程不支持优雅关闭则用gdb附着强制关闭fd高危操作仅限紧急gdb -p 5678 -ex call close(23) -ex quit /dev/null 21其中23是lsof输出的fd号。执行后df -h立即回落那些“deleted”文件占用的空间瞬间释放。4. 根治方案从配置层堵死所有泄漏通道止血只是开始根治才是关键。我们花了两天时间对全系统做了一次“防泄漏加固”核心思路是让每个可能产生临时数据的组件都明确知道自己的“活动半径”和“生存期限”。4.1 journal日志用SystemMaxFiles代替SystemMaxUse默认的/etc/systemd/journald.conf只配置SystemMaxUse500M这在高IO场景下形同虚设。我们改为SystemMaxUse500M SystemMaxFiles100 MaxFileSec1daySystemMaxFiles100强制journald最多保留100个日志文件无论大小配合MaxFileSec1day确保文件按天轮转。这样即使单个日志暴涨也不会突破文件数上限。修改后执行sudo systemctl restart systemd-journald/var/log/journal目录下文件数稳定在90-100之间。4.2 cron任务所有脚本必须自带空间保护逻辑我们审计了所有/etc/cron.*下的脚本发现一个备份脚本/usr/local/bin/backup.sh存在严重隐患# 原始代码危险 tar -czf /backup/$(date %Y%m%d).tar.gz /data # 问题不检查/backup空间不清理过期备份不校验tar是否成功加固后#!/bin/bash BACKUP_DIR/backup # 1. 空间检查剩余空间低于5GB则退出 if [ $(df $BACKUP_DIR | tail -1 | awk {print $4}) -lt 5242880 ]; then logger ERROR: $BACKUP_DIR space low, abort backup exit 1 fi # 2. 清理7天前备份 find $BACKUP_DIR -name *.tar.gz -mtime 7 -delete # 3. 执行备份并校验 tar -czf $BACKUP_DIR/$(date %Y%m%d).tar.gz /data 2/dev/null if [ $? -ne 0 ]; then logger ERROR: tar failed for $(date %Y%m%d) exit 1 fi # 4. 校验tar完整性 if ! tar -tzf $BACKUP_DIR/$(date %Y%m%d).tar.gz /dev/null 21; then logger ERROR: corrupt backup $(date %Y%m%d).tar.gz rm $BACKUP_DIR/$(date %Y%m%d).tar.gz exit 1 fi所有cron脚本都增加了这三层防护从此再未因备份任务引发空间告警。4.3 应用层强制指定临时目录并设置配额很多Java/Python应用默认用/tmp但我们通过环境变量全局重定向# 在/etc/profile.d/tmpdir.sh中添加 export TMPDIR/var/tmp/app export TEMP/var/tmp/app # 创建专用目录并设配额 sudo mkdir -p /var/tmp/app sudo chown app:app /var/tmp/app sudo chmod 1777 /var/tmp/app # 用tmpwatch设置自动清理CentOS/RHEL sudo yum install tmpwatch sudo tmpwatch 24h /var/tmp/apptmpwatch 24h表示自动删除24小时内未访问的文件比cron清理更精准。同时在应用启动脚本中显式指定# Java应用 java -Djava.io.tmpdir/var/tmp/app -jar app.jar # Python应用 export PYTHONTEMP/var/tmp/app python app.py这样所有应用的临时文件都被圈在/var/tmp/app既隔离了风险又便于监控。5. 监控闭环用PrometheusGrafana构建空间预警雷达止血和根治之后必须建立长效监控。我们放弃传统df轮询改用Prometheus的node_exporter指标因为它能直接暴露inode使用率且精度达秒级。5.1 关键指标与告警规则在Prometheus中我们重点关注三个指标node_filesystem_avail_bytes{mountpoint/}根目录可用字节数node_filesystem_files_free{mountpoint/}根目录可用inode数node_filesystem_readonly{mountpoint/}文件系统是否只读OOM Killer触发后常见对应的Grafana告警规则如下- alert: RootFSInodeUsageHigh expr: 100 * (node_filesystem_files_total{mountpoint/} - node_filesystem_files_free{mountpoint/}) / node_filesystem_files_total{mountpoint/} 85 for: 5m labels: severity: warning annotations: summary: Root filesystem inode usage is high description: Root inode usage is {{ $value }}% for more than 5 minutes - alert: RootFSBlockUsageCritical expr: 100 * (node_filesystem_size_bytes{mountpoint/} - node_filesystem_avail_bytes{mountpoint/}) / node_filesystem_size_bytes{mountpoint/} 95 for: 2m labels: severity: critical annotations: summary: Root filesystem block usage is critical description: Root block usage is {{ $value }}% and rising fast注意inode告警阈值85%必须低于block告警95%。因为inode耗尽会导致系统失能而block 95%时系统通常还能苟延残喘。5.2 可视化面板一眼锁定“空间刺客”我们在Grafana创建了一个“Root FS Health”面板包含四个核心图表Top 5 Space Consumers用node_filesystem_usage_bytes按目录聚合显示/var/log、/var/lib等子目录占比Inode Pressure Trend绘制node_filesystem_files_free曲线标注历史低点Journal Size vs Files双Y轴图左轴是journalctl --disk-usage返回的字节数右轴是/var/log/journal下文件数用于识别“小文件爆炸”Ghost Files Count自定义Exporter采集lsof L1 | wc -l结果实时显示被进程占用的已删除文件数这个面板部署后运维同学只需看一眼就能判断是日志疯长、临时文件堆积还是幽灵文件作祟。上周一次告警面板直接显示Ghost Files Count从0飙升至3200我们5分钟内定位到是某个Python爬虫脚本未关闭response流精准修复。实战心得监控不是越多越好。我们只保留这4个图表因为它们覆盖了99%的根目录爆满场景。其他如/proc内存映射、/dev/shm使用率等属于特定场景不纳入主视图。6. 复盘与延伸一次故障暴露的系统性认知偏差这次故障解决后我们组织了一次内部复盘发现真正的问题不在技术而在认知惯性。团队长期存在三个致命误区误区一“df -h是唯一真理”我们过度依赖df -h却忽略了df -i。在容器化时代微服务实例往往只分配几百MB磁盘但默认inode数高达几百万——这导致小文件场景下inode耗尽比block耗尽快10倍。纠正方法将df -i /加入每日巡检checklist和df -h并列第一行。误区二“清理删除”很多人认为rm -rf就是终极解决方案。但Linux的文件系统设计决定了删除只是解除链接真正释放资源需要进程主动close fd或内核回收。正确的清理哲学是先让进程放手再让文件消失。所以lsof L1和kill -HUP必须成为清理流程的固定环节。误区三“配置文件改了就生效”我们曾以为修改journald.conf后重启服务就万事大吉。但实际发现旧日志文件仍保留在磁盘新配置只约束新增日志。真正的生效路径是改配置 →journalctl --vacuum-*→ 重启服务。漏掉中间一步等于白改。这次故障最终推动我们建立了《Linux存储健康黄金法则》所有写入根目录的组件必须配置独立目录如/var/log/app而非/var/log所有临时目录必须挂载为tmpfs或设置tmpwatch自动清理所有日志组件必须同时限制size和files两个维度所有监控告警必须同时覆盖block和inode双指标现在每当新同事入职我们都会带他看一遍那次凌晨3:17的告警记录、lsof L1的输出截图、以及修复后Grafana面板上那条平滑下降的inode曲线。这不是讲技术而是在传递一种敬畏Linux的稳定从来不是靠运气而是靠对每一个字节、每一个inode的精密掌控。我在实际操作中发现最有效的预防不是堆砌工具而是把“空间意识”刻进每个操作习惯里。比如写shell脚本时第一行必加空间检查部署应用时第一件事是确认/tmp挂载方式甚至docker run都要加上--tmpfs /tmp:rw,size1g。这些看似琐碎的动作累积起来就是系统稳定的基石。