Logrotate Bem-sucedido, o arquivo original retorna ao tamanho original

Question

Alguém já teve algum problema com o logrotate antes que isso faça com que um arquivo de log seja rotacionado e, em seguida, volte ao mesmo tamanho original? Aqui estão minhas descobertas:

Script do Logrotate:

/var/log/mylogfile.log {
    rotate 7
    daily
    compress
    olddir /log_archives
    missingok
    notifempty
    copytruncate
}

Saída Detalhada do Logrotate:

copying /var/log/mylogfile.log to /log_archives/mylogfile.log.1
truncating /var/log/mylogfile.log
compressing log with: /bin/gzip
removing old log /log_archives/mylogfile.log.8.gz

Arquivo de log após o truncamento acontecer

[root@server ~]# ls -lh /var/log/mylogfile.log
-rw-rw-r--  1 part1 part1 0 Jan 11 17:32 /var/log/mylogfile.log

Literalmente segundos depois:

[root@server ~]# ls -lh /var/log/mylogfile.log
-rw-rw-r--  1 part1 part1 3.5G Jan 11 17:32 /var/log/mylogfile.log

Versão do RHEL:

[root@server ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux ES release 4 (Nahant Update 4)

Versão do Logrotate:

[root@DAA21529WWW370 ~]# rpm -qa | grep logrotate
logrotate-3.7.1-10.RHEL4

Algumas notas:

• O serviço não pode ser reiniciado na hora, por isso estou usando o copytruncate
• Os registros estão girando todas as noites, de acordo com o diretório olddir que contém arquivos de log de cada noite.

Answer 1

Isso provavelmente ocorre porque, mesmo que você trunque o arquivo, o processo que está sendo gravado no arquivo continuará sendo gravado em qualquer offset que tenha sido enfim. Então, o que está acontecendo é que o logrotate trunca o arquivo, o tamanho é zero, o processo grava no arquivo novamente, continua no offset deixado de lado, e agora você tem um arquivo com bytes NULL até o ponto em que você o truncou mais o novo entradas gravadas no log.

od -c após truncado + crescimento súbito, gerou saída ao longo das linhas de:

0000000  
0000000  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%
*
33255657600  %pre%   C   K   B   -   s   e   r   v   e   r       [   h   t   t
33255657620 <more log output>
  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%  %pre%
*
33255657600  %pre%   C   K   B   -   s   e   r   v   e   r       [   h   t   t
33255657620 <more log output>

O que isto diz é do offset 0 ao 33255657600, o seu arquivo consiste em bytes nulos e, em seguida, em alguns dados legíveis. Chegar a esse estado não leva o mesmo tempo que seria necessário para realmente gravar todos esses bytes nulos. Os sistemas de arquivos ext {2,3,4} suportam algo chamado arquivos esparsos, portanto, se você procurar por uma região de um arquivo que não contém nada, essa região será considerada como contendo bytes nulos e não ocupará espaço no disco. Esses bytes nulos não serão realmente escritos, apenas assumidos como estando lá, portanto, o tempo que leva para ir de 0 a 3.5GB não leva muito tempo. (Você pode testar a quantidade de tempo que leva fazendo algo como dd if=${HOME}/.bashrc of=largefile.bin seek=3432343264 bs=1 , isso deve gerar um arquivo de mais de 3 GB em alguns milissegundos).

Se você executar ls -ls em seus arquivos de registro depois de terem sido truncados e ter um crescimento súbito novamente, ele deverá informar um número no início da linha que representa o tamanho real (em blocos ocupados no disco), que provavelmente é ordens de grandeza menor que o tamanho relatado por apenas ls -l .

    

Answer 2

Estou extremamente confiante de que a Kjetil acertou. Drew, você ainda não pode ser convencido por sua explicação, mas peço-lhe que leia atentamente o que ele disse.

Se você aceitar, a correção é parar e reiniciar o aplicativo quando os logs são girados ou usar uma ferramenta como "rotatelogs" do apache, onde você envia a saída do log para a ferramenta por meio de um pipe e a ferramenta cuida de girar o arquivo de registro de vez em quando. Por exemplo, uma das instâncias do meu apache é registrada com

ErrorLog "|/usr/sbin/rotatelogs /www/logs/error_log 604800"

que causa muitos arquivos de log com nomes como

-rw-r--r--    1 root     root         4078 Dec 21 01:04 error_log.1292457600
-rw-r--r--    1 root     root         4472 Dec 29 08:41 error_log.1293062400
-rw-r--r--    1 root     root        78630 Jan  4 12:57 error_log.1293667200
-rw-r--r--    1 root     root        15753 Jan 12 01:10 error_log.1294272000

para aparecer sem reiniciar o apache; Eu posso comprimi-los manualmente depois do fato. Note como a rotação é feita toda semana, o que é a cada 604800 segundos, sendo esse o argumento passado para rotatelogs .

Se você não pode parar e reiniciar o aplicativo, e ele não pode fazer login por meio de um canal, acho que você tem um problema real. Talvez outros tenham sugestões.

    

Answer 3

seria ótimo se você pudesse enviar o logrotate inteiro.

Por que tentar usar o kill -HUP? (Método de recarregamento clássico não reiniciando ).

Além disso, verifique com lsof quem está acessando o arquivo.

    

Answer 4

Use apenas "> >" o que significa anexar em vez de ">" o que significa criar a partir de seus scripts que gravam neste arquivo. Eu tive exatamente o mesmo problema e consertei usando o app no meu script.

SomeScript.sh > > output.txt

Espero que seja mais claro.