问题大概率出在/var/spool/clientmqueue堆积海量小文件耗尽inode；需先df -i确认inode使用率，再停邮件服务、原子替换清理，并重定向cron输出堵漏。
Linux服务器磁盘空间突然告急，df -h显示根分区使用率超95%，但du -sh *扫不出大目录——问题大概率出在/var/spool/clientmqueue里堆积了数万甚至上百万个0–1KB的邮件队列碎片文件，它们不占多少Block却疯狂消耗inode，导致系统无法创建新文件。
确认clientmqueue是否真为罪魁祸首
执行 df -i 查看 inode 使用率，若 / 分区 IUse% 接近或达到 100%，再运行 du -sh /var/spool/clientmqueue ——如果输出类似“3.2G”或“420K”但 ls | wc -l 显示超50万行，就坐实了：这是海量小文件+高inode占用的典型症状。
注意：不要跳过这一步直接删。有些业务依赖 sendmail 或 mta 服务，盲目清空可能中断未投递的合法邮件任务。
安全停服后原子替换清理（推荐）
第一步：停止 sendmail 或 postfix 服务，防止清理过程中新文件写入：【service sendmail stop】（CentOS 6）或 【systemctl stop postfix】（RHEL/CentOS 7+）。
第二步：将原 clientmqueue 目录重命名为待删除状态：mv /var/spool/clientmqueue /var/spool/clientmqueue-todelete。
第三步：新建空目录并继承原权限：mkdir /var/spool/clientmqueue && chown --reference=/var/spool/clientmqueue-todelete /var/spool/clientmqueue && chmod --reference=/var/spool/clientmqueue-todelete /var/spool/clientmqueue。
第四步：重启邮件服务：【service sendmail start】 或 【systemctl start postfix】，确保新队列可正常工作。
第五步：后台异步删除旧目录：nohup rm -rf /var/spool/clientmqueue-todelete &。这步可放后台跑，不影响业务恢复。
文件太多时绕过参数长度限制的删除法
方法一：用 ls 管道分批传给 rm：cd /var/spool/clientmqueue && ls | xargs rm -f。这是最常用也最稳妥的方式，避免 “Argument list too long” 报错。
方法二：用 find + delete（更精准）：find /var/spool/clientmqueue -type f -delete。它不依赖 shell 参数展开，对千万级文件也稳定，但要求 find 版本支持 -delete（GNU findutils ≥4.2.3）。
方法三：rsync 清空法（极快）：mkdir /tmp/empty && rsync -a --delete-before /tmp/empty/ /var/spool/clientmqueue/。此操作本质是用空目录覆盖目标目录内容，毫秒级完成，但需确保 /tmp 可写且有足够内存缓存。
永久堵漏：从源头禁止垃圾文件再生
检查所有用户的 crontab：crontab -l 和 cat /etc/crontab /etc/cron.d/*，找出未重定向输出的定时任务。
把每条形如 0 2 * * * /backup.sh 的命令，改成 0 2 * * * /backup.sh > /dev/null 2>&1。
这一步最关键：不加重定向的 cron 脚本，只要 stdout 或 stderr 有输出，系统就会尝试发邮件给执行用户；sendmail 若未运行，这些邮件就滞留在 clientmqueue 中变成垃圾。
