Arquivos de log muito grandes, o que devo fazer?

Question

( Esta questão lida com um problema semelhante, mas fala sobre um arquivo de log rotacionado.)

Hoje recebi uma mensagem do sistema referente a muito baixo /var space.

Como de costume, executei os comandos na linha de sudo apt-get clean , o que melhorou o cenário apenas ligeiramente. Então eu excluiu os arquivos de log rotacionados que novamente forneceram muito pouca melhoria.

Após o exame, descubro que alguns arquivos de log no /var/log cresceram para serem muito grandes. Para ser específico, ls -lSh /var/log dá,

total 28G
-rw-r----- 1 syslog            adm      14G Aug 23 21:56 kern.log
-rw-r----- 1 syslog            adm      14G Aug 23 21:56 syslog
-rw-rw-r-- 1 root              utmp    390K Aug 23 21:47 wtmp
-rw-r--r-- 1 root              root    287K Aug 23 21:42 dpkg.log
-rw-rw-r-- 1 root              utmp    287K Aug 23 20:43 lastlog

Como podemos ver, os dois primeiros são os ofensivos. Estou um pouco surpreso por que arquivos tão grandes não foram girados.

Então, o que devo fazer? Basta apagar esses arquivos e depois reiniciar? Ou vá por alguns passos mais prudentes?

Estou usando o Ubuntu 14.04.

UPDATE 1

Para começar, o sistema tem apenas alguns meses. Eu tive que instalar o sistema do zero alguns meses depois de uma falha no disco rígido.

Agora, conforme recomendado em esta resposta , Eu verifiquei pela primeira vez os arquivos de log ofensivos usando tail , sem surpresa. Então, para uma inspeção mais profunda, eu executei este script a partir da mesma resposta .

for log in /var/log/{syslog,kern.log}; do 
  echo "${log} :"
  sed -e 's/\[[^]]\+\]//' -e 's/.*[0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\}//' ${log} \
  | sort | uniq -c | sort -hr | head -10
done

O processo levou várias horas. A saída estava na linha de

/var/log/syslog :
71209229  Rafid-Hamiz-Dell kernel:  sda3: rw=1, want=7638104968240336200, limit=1681522688
53929977  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
17280298  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
   1639  Rafid-Hamiz-Dell kernel:  EXT4-fs warning (device sda3): ext4_end_bio:317: I/O error -5 writing to inode 6819258 (offset 0 size 4096 starting block 54763121030042024)
       <snipped>

/var/log/kern.log.1 :
71210257  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
71209212  Rafid-Hamiz-Dell kernel:  sda3: rw=1, want=7638104968240336200, limit=1681522688
   1639  Rafid-Hamiz-Dell kernel:  EXT4-fs warning (device sda3): ext4_end_bio:317: I/O error -5 writing to inode 6819258 (offset 0 size 4096 starting block 954763121030042024)

( /dev/sda3 é o meu diretório inicial. Como podemos encontrar,

lsblk /dev/sda
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931.5G  0 disk 
├─sda1   8:1    0 122.1G  0 part /
├─sda2   8:2    0   7.6G  0 part [SWAP]
└─sda3   8:3    0 801.8G  0 part /home

Por que um processo vai querer escrever além do limite está fora do escopo da minha compreensão. Talvez eu queira fazer uma pergunta diferente neste fórum se continua mesmo depois de uma atualização do sistema.)

Então, a partir de esta resposta (você pode querer verificar isso para uma compreensão mais profunda), eu executado,

sudo su -
> kern.log
> syslog

Agora, esses arquivos têm tamanho zero. O sistema está funcionando bem antes e depois de uma reinicialização.

Eu assistirei esses arquivos (junto com outros) nos próximos dias e reportarei de volta se deveria eles se comportam fora de linha.

Como nota final, os arquivos ofensivos ( kern.log e syslog ) estão configurados para serem rotacionados, conforme a inspeção dos arquivos ( grep ajudou) dentro /etc/logrotate.d/ mostra.

UPDATE 2

Os arquivos de log são realmente rotacionados. Parece que os tamanhos grandes foram atingidos em um único dia.

    

Answer 1

  

Basta apagar esses arquivos e depois reiniciar?

Não. Esvazie-os, mas não use rm , pois ele pode acabar causando problemas enquanto você digita o comando touch para recriá-lo.

Método mais curto:

cd /var/log
sudo su
> lastlog
> wtmp
> dpkg.log 
> kern.log
> syslog
exit

Se não for root, será necessário sudo . Extraído de outra resposta na AU.

ANTES DE VOCÊ FAZER ISSO. Faça um tail {logfile} e verifique se existe uma razão para eles serem tão grandes. A menos que este sistema tenha vários anos, não deve haver razão para isso e consertar o problema é melhor do que deixar isso acontecer.

O kern.log e o syslog normalmente não devem ser tão grandes. Mas como eu disse: se este sistema está funcionando há anos e anos, pode ser normal e os arquivos precisam ser apagados.

E para evitar que ele se torne tão grande no futuro: setup logrotate . É bastante simples e irá comprimir o arquivo de log quando ele ficar maior que o tamanho que você definiu.

1 outra coisa: se você não deseja excluir o conteúdo, você pode compactar os arquivos com tarring ou gzipping deles. Isso fará com que você acabe com arquivos provavelmente 10% do que eles são agora. Isto é, se ainda houver espaço no disco para fazer isso.

    

Answer 2

Provavelmente vale a pena tentar determinar o que está preenchendo o (s) registro (s) - seja simplesmente examinando-os visualmente usando o comando less ou tail

tail -n 100 /var/log/syslog

ou se as linhas ofensivas estiverem muito enterradas para ver facilmente o que está ocorrendo, algo como

for log in /var/log/{dmesg,syslog,kern.log}; do 
  echo "${log} :"
  sed -e 's/\[[^]]\+\]//' -e 's/.*[0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\}//' ${log} \
  | sort | uniq -c | sort -hr | head -10
done

(nota: isso pode levar algum tempo, dados arquivos tão grandes), que tentará remover os timestamps e depois contar as mensagens mais frequentes.

    

Answer 3

Meu método para arquivos de log do sistema limpo é este. As etapas 1 e 2 são opcionais, mas às vezes você precisa verificar os logs mais antigos e o backup às vezes é útil. ; -)

1. Opcional: Copiar arquivo de log

   cp -av --backup=numbered file.log file.log.old
   

2. Opcional: Use o Gzip na cópia do log

   gzip file.log.old
   

3. Use / dev / null para arquivo limpo

   cat /dev/null > file.log
   

E nós usamos para este logs (somente em vários servidores) logrotate e semanalmente executamos pelo script cron que todos os arquivos com * .1 (ou o próximo rotacionado) comprimir por gzip.

    

Answer 4

Eu instalei o Ubuntu 16.04 hoje e notei o mesmo problema. No entanto, eu corrijo isso com busybox-syslogd. Sim! Acabei de instalar esse pacote e o problema foi resolvido. :)

$ sudo apt-get install busybox-syslogd

Depois de instalar o pacote, redefina syslog e kern.log :

sudo tee /var/log/syslog /var/log/kern.log </dev/null

Espero que esta solução simples seja útil para outras pessoas.