nohup.out 涨到 30G，jar 包服务的日志没人切

下面按现场排查习惯来写，能直接复制的命令放在代码块里，顺序照做即可。 用 nohup java -jar 起的后端服务跑了两个月，nohup.out 不知不觉长到三十 G，磁盘告警时才发现应用的标准输出一直是无界追加。

多数情况下不用停机，但涉及重启服务时最好挑低峰期。

先分清是哪一类原因

1. 启动脚本没有重定向到单独的日志文件，输出全部进了 nohup.out
2. logback 只切自己写的业务日志，标准输出这一路仍然无限增长
3. 没有配 logrotate 规则，压缩和删除的环节完全没有人管

按顺序处理

1. 确认是哪个进程在写这个文件

lsof /opt/app/nohup.out

2. 清空而不删除，避免 inode 残留

truncate -s 0 /opt/app/nohup.out

3. 补一条 logrotate 规则并演练

logrotate -d /etc/logrotate.d/app

4. 重启时改成带日期的输出文件

nohup java -jar app.jar > app.log 2>&1 &

怎么确认已经恢复

nohup.out 大小回到零，logrotate 手动执行后能按天生成 .1 和 .gz 文件，磁盘占用保持稳定。

容易忽略的地方

copytruncate 存在丢日志的时间窗口，能改应用输出路径就改；jar 包的启动脚本要写进部署规范，否则下次换机器又会重犯。 命令执行完不要只看有没有报错，还要看输出里的计数和状态码是否符合预期。