linux设置jboss日志覆盖,Linux Jboss下logback日志框架的输出日志只保留10天的问题

一、问题描述

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

/tmp/logs/hyInfo.logfile>

/tmp/logs/hyInfo-%d{yyyy-MM-dd}.logfileNamePattern>

180maxHistory>

rollingPolicy>

%d{HH:mm:ss.SSS} [%thread] %-5level %logger{5} - %msg%npattern>

encoder>

falseappend>

falseprudent>

appender>

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服务器时还得专门留意这个脚本的修改，不太方便。