inode耗尽是“no space left on device”等报错的真因，本质是大量小文件（如cron未重定向输出导致的邮件堆积）占满固定数量的inode；需用df -i确认，du --inodes或find定位，清理/var/spool/postfix/maildrop等目录，并通过mailto=""或重定向预防复发。
定时任务本身不报错，但系统变慢、磁盘 inode 耗尽、ls 卡顿、甚至提示“无法创建临时文件：设备上没有空间”，这类现象往往不是磁盘空间满，而是被大量小文件占光了 inode。而根源常是 crontab 任务未处理输出，导致邮件队列堆积——每个失败或有输出的任务都会生成一个待投递邮件文件，最终在 /var/spool/postfix/maildrop 或 /var/spool/clientmqueue 下积累成千上万个空（或极小）文件。
确认是否 inode 耗尽
运行以下命令检查根分区 inode 使用率：
df -i /
若 Use% 接近 100%，且 Inodes 数量极大（如几百万），就基本锁定是 inode 问题。再定位高文件数目录：
-
find /var -xdev -type f | wc -l—— 查看/var下总文件数 -
ls -lR /var/spool/postfix/maildrop 2>/dev/null | wc -l—— 直接检查邮件暂存目录 -
ls -lR /var/spool/clientmqueue 2>/dev/null | wc -l—— 若用 sendmail 或旧版 MTA，查此目录
快速清理已堆积的空文件
确认目录后，安全清空（注意：先备份关键邮件或确认无业务依赖）：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 进入对应目录，如：
cd /var/spool/postfix/maildrop - 删除所有文件：
find . -type f -delete（比xargs rm更安全） - 清空 root 邮箱（避免后续读取卡顿）：
echo > /var/spool/mail/root
清理后再次执行 df -i /，应看到 Use% 明显下降。
定位并修复产生空文件的定时任务
这些空文件本质是 cron 输出未重定向导致的“待发邮件”。排查重点在 crontab 中是否有以下特征的任务：
- 每分钟或高频执行（如
* * * * *） - 命令末尾无任何重定向（缺少
> /dev/null 2>&1或日志路径） - 脚本本身静默失败（如权限错误、路径错误），只输出错误到 stderr，却未被捕获
检查方式：
- 用户级任务：
crontab -l - 系统级任务：
sudo cat /etc/crontab和/etc/cron.d/下所有文件 - 重点关注那些“看起来没输出”的命令——其实只要 stdout 或 stderr 有内容（哪怕只是
echo或失败提示），就会触发邮件机制
预防措施：从配置源头杜绝空文件
修复后务必加固，避免复发：
- 所有新写的 crontab 条目，末尾必须加上：
> /dev/null 2>&1 - 如需保留记录，改用追加写入日志：
>> /var/log/myjob.log 2>&1，并配合 logrotate - 在 crontab 文件顶部添加：
MAILTO=""（全局禁用邮件通知，适用于无需收任务反馈的场景） - 对关键脚本，加一行简单日志头：
echo "[$(date)] START" >> /var/log/myjob.log，便于确认是否真在执行
不复杂但容易忽略。关键在于：cron 的默认行为是“有输出就发邮件”，而没人收的邮件，就变成文件躺在磁盘上等你发现。
