服务器跑着跑着磁盘突然爆了，一查发现是某个服务的日志文件涨到了几十GB。这种情况太常见了，尤其是那些没配置自动轮转的老服务。其实不用等系统自动处理，完全可以手动执行日志轮转命令来快速缓解问题。
为什么需要手动触发日志轮转
大多数 Linux 系统都用 logrotate 管理日志切割，但它默认靠 cron 每天执行一次。如果某天访问量猛增，日志暴涨，等到第二天再处理可能已经迟了。这时候就得主动出手，让 logrotate 马上干活。
怎么手动运行 logrotate
最直接的方式就是用 root 或有权限的用户执行下面这条命令：
/usr/sbin/logrotate -f /etc/logrotate.d/your-service-name比如你发现 Nginx 的 access.log 太大，可以单独处理它：
/usr/sbin/logrotate -f /etc/logrotate.d/nginx加上 -f 参数就是强制执行，不管是否满足时间或大小条件，都会立刻做切割。
想全局处理所有服务怎么办
如果你懒得一个个配，也可以直接刷整个配置目录：
/usr/sbin/logrotate -f /etc/logrotate.conf这会读取主配置文件里的 include 指令，把所有子配置都走一遍。适合在维护窗口统一清理一轮。
执行完之后注意什么
命令跑完不代表万事大吉。得去看看旧日志是不是被重命名了，新日志有没有正常生成。更重要的是：很多服务不会自动打开新文件句柄，得发个 HUP 信号通知它重新加载日志文件。
比如 Nginx 就要补一句：
kill -HUP $(cat /var/run/nginx.pid)不然你会发现新日志写不进去，老进程还抓着已经被 rename 的文件不放，磁盘空间也释放不了。
临时救急的小技巧
有时候你连 logrotate 配置都没准备好，但当前日志实在太大，就想先切一下再说。可以手动改名日志文件：
mv /var/log/app/access.log /var/log/app/access.log.old然后通知服务 reload，接着再用 touch 把原文件重建出来：
touch /var/log/app/access.log这招快，但只是权宜之计。长期还是得配上正确的 logrotate 规则，避免下次再手忙脚乱。