Linux Jboss下logback日志框架的输出日志只保留10天的问题

一、问题描述
出现该问题的基本运行环境为：操作系统为Linux CentOS 6.5 64bit，Jboss为4.3.0 GA版本，logback版本为1.1.2，日志配置文件如下：

<appender name="rollingAppender" class="ch.qos.logback.core.rolling.RollingFileAppender"> 
    <file>/tmp/logs/hyInfo.logfile> 
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> 
        <fileNamePattern>/tmp/logs/hyInfo-%d{yyyy-MM-dd}.logfileNamePattern> 
        <maxHistory>180maxHistory> 
    rollingPolicy> 
    <encoder> 
        <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{5} - %msg%npattern> 
    encoder> 
    <append>falseappend> 
    <prudent>falseprudent> 
appender> 
 
<root level="INFO"> 
    <appender-ref ref="rollingAppender" /> 
root>

日志配置在/tmp/logs目录下，若按预期的配置，日志文件应该是能保存180天，但实际情况是该目录下的日志只能保留最近的10个，其余全部被删除了。

二、初步分析
以上出现问题的环境是实际的测试环境和生产环境，但是本地研发环境使用的是Windows操作系统和Jboss 4.3.0 GA，经对比分析，发现在Windows下是能够正常保存180天日志的（可以通过修改系统时间来产生多天的日志）。这个就奇怪了，难道是logback在Linux环境有不兼容的情况？只能通过远程调试的方式+用root用户权限修改系统时间来模拟，硬是把相关的源码跑了一遍，结果显示保存的日志文件是可以超过10个的，这下就更奇怪了，不过可以证实logback日志框架在Linux下是正常的，但日志又是谁删除了呢？

三、原因分析
只能带着这个问题继续找答案了，既然logback是正常的，Windows系统下也是正常的，只是在Linux操作系统会出现日志非预期删除，那猜想应该是Linux有自动清理任务了，顺着这个思路还真被我找到了：Linux下有个tmpwatch工具，是专门清理/tmp下面的文件的，使用命令vi /etc/cron.daily/tmpwatch能看到执行的脚本：

#! /bin/sh
flags=-umc
/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
        -x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \
        -X '/tmp/hsperfdata_*' 10d /tmp
/usr/sbin/tmpwatch "$flags" 30d /var/tmp
for d in /var/{cache/man,catman}/{cat?,X11R6/cat?,local/cat?}; do
    if [ -d "$d" ]; then
        /usr/sbin/tmpwatch "$flags" -f 30d "$d"
    fi
done

大致的意思是递归删除/tmp目录下的超过10天未修改的文件和/var.tmp目录下超过30天未修改的文件。

使用命令cat /etc/anacrontab 可以看到tmpwatch执行的时间：

# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22

#period in days   delay in minutes   job-identifier   command
1    5    cron.daily        nice run-parts /etc/cron.daily
7    25    cron.weekly        nice run-parts /etc/cron.weekly
@monthly 45    cron.monthly        nice run-parts /etc/cron.monthly

注：run-parts命令是指执行/etc/cron.daily目录下所有的可执行文件。

可以看到tmpwatch调度任务的执行时间是从3点到11点，执行频率为1天1次，而之前我们修改系统时间来模拟日志输出是改成23:59:55时间点，过了零点再生成日志，反复这样修改，没有遇上tmpwatch的任务执行，所以日志能保存下来。

四、解决方案
找到了原因，那解决方案就好办了，一种是修改tmpwatch的删除未修改文件时间为180天，另一种是将日志全部移植到其他目录下，如/app/logs下，通过logback框架自带的清理功能对日志文件进行清理，不再使用系统自带的tmpwatch清理功能。
建议使用第二种方案，因为第一种方案会因为间隔时间设置过大导致/tmp目录下的所有文件存放过久，占用硬盘空间，并且当开发的应用系统迁移到另外的Linux服务器时还得专门留意这个脚本的修改，不太方便。