Java中Logback/Log4j2与logrotate协同问题：如何始终写入指定日志文件

这是运维和Java日志配置里很常见的坑，我来帮你拆解问题本质，再给出针对Logback和Log4j2的具体解决方案：

问题根源：文件句柄 vs 文件名 #

不管是Logback还是Log4j2，默认都是通过文件句柄（而非文件名）来写入日志的。当logrotate把application.log重命名为application.log.1时，只是修改了文件的名称，底层的文件inode和应用持有的文件句柄并没有变化——所以Java应用会继续往这个“旧句柄”对应的文件（也就是现在的application.log.1）写日志，而不是新创建的application.log。

不用copytruncate的安全解决方案 #

你不想用copytruncate是非常合理的，这个选项确实存在日志丢失风险（复制和截断之间的时间差里，新写入的日志可能会丢失）。正确的做法是让日志组件在logrotate完成轮转后，主动关闭旧文件句柄，重新打开新的application.log文件，具体分两种情况：

针对Logback的配置 #

1. 保持你的Logback配置不变，确保FileAppender指向application.log，且append属性为true（默认就是true，不用额外改）。
2. 修改你的logrotate配置文件，添加postrotate脚本，发送SIGUSR1信号给Java进程——Logback默认监听这个信号，收到后会自动重新打开日志文件：

/var/log/application.log {
    size 1M
    rotate 5
    missingok
    notifempty
    # 轮转完成后发送信号给Java进程
    postrotate
        # 替换成你的Java进程标识（主类名或jar包名）
        pkill -USR1 -f "com.yourcompany.YourMainClass"
    endscript
}

测试一下：当logrotate完成轮转后，Java进程会收到SIGUSR1，Logback会关闭旧的文件句柄，重新打开application.log，之后的日志就会写入新文件了。

针对Log4j2的配置 #

Log4j2的处理逻辑类似，但默认监听的是SIGHUP信号，调整logrotate配置即可：

/var/log/application.log {
    size 1M
    rotate 5
    missingok
    notifempty
    postrotate
        # 替换成你的Java进程标识
        pkill -HUP -f "com.yourcompany.YourMainClass"
    endscript
}

如果你的Log4j2配置自定义了信号处理，可以通过log4j2.component.properties里的log4j2.signal.reconfigure修改触发信号，不过默认的SIGHUP已经够用。

额外注意事项 #

• 确保pkill能精准匹配到你的Java进程：如果有多个同名进程，可以用pgrep先确认进程ID，再用kill -USR1 <pid>发送信号。
• 容器部署场景：如果应用跑在Docker/K8s里，需要在宿主机上找到容器对应的PID（可以用docker inspect <container-id> | grep Pid），再发送信号；或者在容器内安装procps工具，直接在容器内执行信号发送命令。
• 权限问题：执行logrotate的用户需要有发送信号给Java进程的权限，通常root用户没问题，如果是普通用户，需要确保用户有进程的访问权限。

内容的提问来源于stack exchange，提问作者Shubham