一、問題描述
出現該問題的基本執行環境為：作業系統為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.log</file> 
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"
 
> 
        <fileNamePattern>/tmp/logs/hyInfo-%d{yyyy-MM-dd}.log</fileNamePattern> 
        <maxHistory>180</maxHistory> 
    </rollingPolicy> 
    <encoder> 
        <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{5} - %msg%n</pattern> 
    </encoder
 
> 
    <append>false</append> 
    <prudent>false</prudent> 
</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伺服器時還得專門留意這個指令碼的修改，不太方便。