Por que o JBoss e o Logrotate criam arquivos de log cheios de caracteres NUL?

Question

Eu configurei o Logrotate para girar meus logs do JBoss Application Server 4.2.2.GA todas as noites. Depois que os arquivos de log foram girados e o JBoss começa a gravar para eles novamente, os novos arquivos de log começam com quantos caracteres NUL houver caracteres no arquivo de log anterior, seguidos pelas novas mensagens de log. Por exemplo, se o arquivo server.log do JBoss tiver 5000 bytes, então, após a rotação, o novo arquivo server.log começará com 5000 caracteres NUL. Após vários dias, server.log começa com caracteres NUL equivalentes aos caracteres de todos os arquivos de log dos dias anteriores combinados. Parece que o JBoss está lembrando sua posição no arquivo de log e pegando de onde parou no arquivo truncado. Aqui está minha configuração de logrotate para o JBoss:

/apps/jboss-4.2.2.GA/server/default/log/*log {
    daily
    rotate 30
    compress
    notifempty
    copytruncate
    missingok
    nocreate
}

Eu não posso reiniciar o JBoss todas as noites porque isso seria muito tempo de inatividade. Eu também não posso usar o log4j DailyRollingFileAppender como ele não exclui arquivos de log antigos. Alguém conseguiu logrotate funcionando corretamente com o JBoss?

    

Answer 1

Tivemos o mesmo problema para um arquivo sendo gravado por log4j. A solução foi definir a propriedade "Append" para o FileAppender como "true". Após essa mudança, não vimos esse problema com arquivos com NUL quando rotacionados por um programa externo como logrotate.

    

Answer 2

Da minha experiência - e a razão pela qual não usamos logrotate com Log4j é que a maneira como o logrotate funciona é que ele renomeia os arquivos, então instrui o programa a fechar seus logs e reabri-los com o nome antigo do arquivo (o que não existe mais), normalmente usando o sinal HUP.

Mas Log4j não pode ser instruído a reabrir seus arquivos de log, então eu vejo você usar copytruncate para copiar os arquivos - o problema é que Log4j usa escritores em buffer que controlam a posição atual do arquivo que está sendo escrito e quando você trunca o arquivo de log, log4j continua escrevendo de onde parou de gravar antes do truncamento. Dependendo da sua implementação do sistema de arquivos, isso deve criar "arquivos com falhas" - ou seja, os caracteres NULL que você vê não existem - o arquivo é tão grande quanto os dados reais e o caractere NULL é o modo como o visualizador representa o arquivo buraco. Alguns sistemas de arquivos, por outro lado, não suportam falhas e, de fato, preenchem o arquivo com caracteres NULL quando o Log4j retoma a gravação.

Sugiro - não use logrotate, encontre uma maneira de girar os arquivos dentro do Log4j usando um RollingFileAppender (que suporta a remoção de arquivos antigos) ou usando o DailyRollingFileAppender e um cronjob que remova arquivos antigos externamente (como era para ser feito).

    

Answer 3

Isso funciona perfeitamente. Para resumir o que @Guss sugeriu:

1. Abra o seu "log4j.xml" e adicione o seguinte apêndice (usei a classe DailyRollingAppender e configurei-a para rollover diariamente):

* NOTA: A frequência do rollover é baseada no "DatePattern". Veja: link

<appender name="RollingAppender" class="org.apache.log4j.DailyRollingFileAppender">
       <param name="File" value="/logging_directory_path_here/server1.log" />
       <param name="DatePattern" value="'.'yyyy-MM-dd" />
       <layout class="org.apache.log4j.PatternLayout">
          <param name="ConversionPattern" value="[%p] %d %c %M - %m%n"/>          
       </layout>
    </appender>

    <root>
            <priority value="info" />
            <appender-ref ref="RollingAppender" />
    </root>

2. Crie um script de shell que comprima o arquivo de log com rolagem.
3. Instale esse Script Shell no Crontab do Unix Server para que ele seja executado diariamente. por exemplo. É executado diariamente às 12:10 am (Por que 12:10 am? Isso dá tempo suficiente para log4j concluir a substituição, apenas no caso de o (s) arquivo (s) de log ser / são muito grandes ou se houver muitos arquivos de log para comprimir).
4. Finalmente, verifique se o log4j Rollover é executado às 12:00 (padrão) e a tarefa cron que executa o script de shell às 12:10 am.m