Arquivo logrotation do Linux mostrando tamanho incorreto do que o normal

Question

Eu habilitei o logrotation no diretório springboot e está funcionando, mas o que vejo é que "content-data-svc.log" tem na verdade 2 MB, mas quando faço ls -ltrh ele aparece como 61 MB.

se eu visualizar o arquivo de log, haverá mais linhas vazias no arquivo de log e, portanto, criará um tamanho de arquivo grande. 50% do arquivo de log está com espaço vazio e o restante são entradas de log. Alguma ideia de por que isso está ocorrendo?

[aemelics@springboot]$ ls -ltrh
total 4.6M
-rw------- 1 aemelics aemelics 1.6M Apr 11 06:44 content-data-svc.log.2.gz
-rw------- 1 aemelics aemelics 1.1M Apr 12 00:44 content-data-svc.log.1.gz
-rw------- 1 aemelics aemelics  61M Apr 12 02:00 content-data-svc.log
[aemelics@springboot]$ du -shx content-data-svc.log
2.0M    content-data-svc.log

Abaixo estão minhas entradas de logrotate:

[aemelics@springboot]$ cat /etc/logrotate.d/react

/logs/springboot/*.log*
{
su aemelics aemelics
    missingok
    daily
    minsize 20M
    copytruncate
    notifempty
    sharedscripts
    compress
    rotate 5
    postrotate
    endscript
}

Answer 1

A razão pela qual o arquivo parece grande na saída de, lsmas pequeno na saída de du, e parece haver espaço vazio no início do arquivo após a rotação é que qualquer programa que esteja gravando no arquivo de log énãoabrindo o arquivo para "anexar" a.

Quando o arquivo de log é girado, com a copytruncateopção definida no logrotatearquivo de configuração, uma cópia do arquivo é criada e o arquivo original étruncado. Quando um arquivo é truncado, seu conteúdo é efetivamente excluído, mas o arquivo em si não é excluído.

Normalmente, um programa teria aberto o arquivo para anexar. Isso significa que cada nova gravação no log acontece nofimdo arquivo, sempre. Quando o arquivo é truncado, isso significa que a próxima linha de log será escrita no início do arquivo, porque é também onde está o final naquele ponto.

Contudo, se o programanão temabriu o arquivo no modo de acréscimo, a próxima gravação irá para qualquer deslocamento no arquivo em que a última gravação foi concluída, independentemente de o arquivo ter sido truncado ou não.

Se o arquivo foi truncado por logrotate, isso significa que a gravação cria um buraco no arquivo entre o início e o ponto onde a gravação acontece. Este buraco está cheio de bytes nulos, que o vieditor mostra como ^@.

Isto é o que acontece no seu caso.

Uma lima com esse furo é chamada de lima "esparsa". Os bytes nulos no buraco em si não são realmente armazenados no disco, e é por isso que dumostram um tamanho bem pequeno, mas se você ler o arquivo do início ao fim, você leria 61M de dados (o tamanho lógico do arquivo, que é o que lsmostra).

Para resolver isso, ou

1. reescrever o programa que grava no arquivo de log para que ele abra o arquivo no modo de acréscimo ou
2. diga ao programa parareabriro arquivo de log quando o arquivo é girado (isso geralmente é feito enviando ao programa um HUPsinal de logrotate, mas você deve ler o manual do seu programa), ou
3. reinicie o programa a partir do logrotatemomento em que o log for girado.