logback服务器不自动切割日志，本地可以（非代码原因）

项目场景：

某次排查问题突然发现生产服务器log日志不进行切割了，导致info.log日志文件越来越大。

---

问题描述

使用logback日志文件，服务器日志突然不进行切割，排查发现logback本身配置并没有问题 本地使用同样的代码进行复现，发现可以正常切割，代表不是配置问题。

---

原因分析：

在logback.xml文件中增加配置，并在启动命令时，增加命令
原：nohup java -Xms4096m -Xmx4096m -Dfile.encoding=UTF-8 -jar xxx.jar > /dev/null 2>&1 &

现：nohup java -Dlogback.statusListenerClass=ch.qos.logback.core.status.OnConsoleStatusListener -Dlogback.debug=true -Xms4096m -Xmx4096m -Dfile.encoding=UTF-8 -jar xxx.jar &

logback.xml 增加

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>
    <root level="INFO">
        <appender-ref ref="STDOUT" />
   </root>

上述命令的作用是打印出logback本身的日志内容，在启动项目后，查看nohup.out内容

按照配置要求再次更改logback.xml配置，取消掉file的配置
Please consider leaving the [file] option of RollingFileAppender empty

    <appender name="info" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!-- 注释此段代码 -->
        <!--<file>${log.path}/info.log</file> -->
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>${log.path}/info/%d{yyyy-MM, aux}/log_info_%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
            <maxHistory>${maxHistory}</maxHistory>
            <maxFileSize>${maxFileSize}</maxFileSize>
            <totalSizeCap>${totalSizeCap}</totalSizeCap>
        </rollingPolicy>
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <!--<pattern>%date [%thread] %-5level [%logger{50}] %file:%line - %msg%n</pattern>-->
            <pattern>${common-pattern-color}</pattern>
        </encoder>
        <filter class="ch.qos.logback.classic.filter.LevelFilter"><!-- 只打印INFO日志 -->
            <level>INFO</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
    </appender>

再次运行，发现最终报错原因

根据logback报错内容看，是最终往debug/2024-04文件夹下写文件是权限拒绝了，查看实际的文件夹，发现此文件夹的权限是root用户，但是启动jar命令时admin用户执行。

原因：是之前有一次不小心在生产环境用root启动了一次jar，虽然后续重新启动改成了admin，但是导致文件夹是root用户创建的，所以其他用户进行写文件失败

---

解决方案：

提示：将对应文件夹改为admin用户（启动jar的用户）
chown -R admin:admin /data/service/logs
更改好后权限，等待几分钟后，发现系统自动进行了切割文件