应使用 sudo truncate -s 0 /var/log/maillog 或 sudo > /var/log/maillog 清空日志，避免 rm 破坏文件句柄；清空前需验证服务是否真在写该文件，并确认 rsyslog 配置；清空后若无新日志，需检查 rsyslog 是否重载、模板路径是否正确及 selinux 是否拦截；长期应配置 logrotate 自动轮转并确保 cron 调度生效。
直接清空 /var/log/maillog 不中断服务的正确操作
直接 rm /var/log/maillog 会破坏邮件服务（如 Postfix、Sendmail）正在持有的文件句柄，导致后续日志写入失败甚至服务卡死。必须保留文件 inode 和权限，只清空内容。
推荐用 truncate -s 0 或重定向 >，两者都安全，但适用场景略有差异：
-
sudo truncate -s 0 /var/log/maillog：对超大文件（比如几 GB）更高效，不读取原内容，瞬间完成 -
sudo > /var/log/maillog：最轻量，不依赖额外命令，适合脚本批量处理多个日志 - 避免
echo "" > /var/log/maillog：会写入一个换行符，文件大小变成 1 字节，某些监控脚本或日志轮转逻辑可能误判为“非空”
清空前先确认服务是否在写这个文件
有些系统把邮件日志转发给 rsyslog 或 systemd-journald，实际 /var/log/maillog 可能已停用。执行以下命令验证：
-
ls -l /var/log/maillog：看文件是否存在、大小是否持续增长 -
sudo lsof +D /var/log | grep maillog：若有输出，说明有进程正打开并写入该文件 -
grep "mail.*" /etc/rsyslog.conf /etc/rsyslog.d/*.conf 2>/dev/null：确认 rsyslog 是否仍配置向该路径写入
如果没进程在用、且 rsyslog 配置里也找不到对应规则，那这个文件可能只是历史残留，可直接 rm ——但别急着删，先 stat /var/log/maillog 看下最后修改时间，避免误删活跃日志。
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
清空后服务没继续写新日志？检查三个关键点
清空后发现日志不再增长，不是方法错了，而是服务本身没重启写入逻辑。常见原因：
- Postfix 默认不直接写
/var/log/maillog，而是发给rsyslog；清空后需触发 rsyslog 重新加载：sudo pkill -HUP rsyslogd - rsyslog 配置中用了
$ActionFileDefaultTemplate或template定义了日志格式，但模板路径写错，导致写入失败（查/var/log/messages里有没有 rsyslog 报错） - SELinux 启用时，
truncate或重定向可能被阻止；运行ausearch -m avc -ts recent | grep maillog看是否有拒绝记录
长期管理别只靠手动清空
反复手动清空治标不治本。真正省心的做法是配 logrotate 自动轮转：
- 新建
/etc/logrotate.d/postfix（或sendmail），内容如下：
"/var/log/maillog" {
daily
missingok
notifempty
compress
delaycompress
rotate 14
create 640 root root
sharedscripts
postrotate
if systemctl is-active --quiet rsyslog; then
systemctl kill --signal=SIGUSR1 rsyslog
fi
endscript
}
重点注意：postrotate 段必须通知 rsyslog 重开文件，否则它还在往旧 inode 写。另外，create 权限要和原文件一致（用 ls -l /var/log/maillog 查），否则新日志可能因权限不足写不进去。
真正容易被忽略的是：轮转配置生效前，得先确保 logrotate 已被 cron 调度。检查 /etc/cron.daily/logrotate 是否存在且可执行——很多最小化安装的系统默认没启用它。
