/tmp、/var/tmp、/dev/shm 是磁盘告警高频源头，需通过 du 定位占用、find/lsof 查增长源、lsof +l1 识别已删未释文件，并加固清理策略与权限管控。
临时文件目录长期不清理是 Linux 磁盘告警的高频原因，尤其集中在 /tmp、/var/tmp 和 /dev/shm 这三个位置。它们可写、易忽略、默认无自动清理策略（或策略失效），一旦应用行为异常或脚本失控，几小时就能吃掉几十 GB 空间。排查不能只靠“删完再说”，得从占用事实、增长源头、残留痕迹三方面入手。
确认是否真被临时目录占满
先别进目录 ls，直接用 du 快速定位：
-
du -sh /tmp /var/tmp /dev/shm 2>/dev/null | sort -hr—— 查看这三个目录当前总大小，一眼看出谁异常 -
du -sh /tmp/* 2>/dev/null | sort -hr | head -10—— 如果 /tmp 大，进一步看它下面哪些子项最占空间 - 注意：
/dev/shm是内存文件系统（tmpfs），df -h里会单独显示，如果它 Use% 高，说明不是磁盘问题，而是内存被大量共享内存段占用
查清是谁在往里写、写了什么
临时目录爆满往往不是静态堆积，而是有进程持续写入。重点看两类内容：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
大文件：用
find /tmp -type f -size +50M -ls 2>/dev/null | sort -k7 -nr | head -20找出大于 50MB 的活跃文件，留意创建时间、属主和名字（比如app_cache_20260924.log或dump_*.bin） -
海量小文件：执行
find /tmp -maxdepth 2 -type f | wc -l，如果数字超过 10 万，再用for d in /tmp/*/; do [ -d "$d" ] && echo "$(find "$d" -type f | wc -l) $d"; done | sort -nr | head -5定位密集子目录 - 结合
lsof +D /tmp查看哪些进程正在读写 /tmp 下的文件，特别是处于REG（普通文件）或DEL（已删除但未释放）状态的句柄
识别“删了也不释放”的幽灵文件
常见于日志类服务——文件被 rm 删除，但进程仍持有句柄继续写，空间卡死不归还：
- 运行
lsof +L1 /tmp 2>/dev/null，输出中带DEL标记的行就是罪魁祸首，Size 列显示实际占用空间 - 典型场景：Java 应用把日志输出到
/tmp/app.log，运维手动rm /tmp/app.log，但 JVM 进程没重启，日志仍在往已删除文件写，df显示满，du却统计不到 - 解决办法不是再删，而是重启对应进程，或让其重新打开日志文件（如发
SIGHUP，视服务支持而定）
加固与预防：让临时目录不再失控
排查只是救火，关键要堵住漏洞：
- 检查
/etc/systemd/system.conf中DefaultTimeoutStopSec和RuntimeDirectoryMode设置，确保 systemd-tmpfiles 清理机制生效；运行systemd-tmpfiles --clean --all手动触发一次 - 对业务强依赖的临时目录（如
/tmp/myapp），改用独立子目录 + 严格权限（chmod 1755粘滞位），并配find /tmp/myapp -type f -mmin +1440 -delete类定时任务 - 禁止将
/dev/shm用于持久缓存，它本意是进程间高速通信，不是存储区；发现异常大文件立即查ps aux | grep shm - 在监控侧加一层校验：对
/tmp目录设置inotifywait -m -e create,modify /tmp日志捕获，结合文件名黑白名单做实时告警
