Existe uma maneira adequada de limpar logs?

Eu queria saber se havia uma maneira adequada de limpar os logs em geral?

Eu sou novo no Ubuntu e estou tentando configurar o Postfix. O log em questão é /var/log/mail.log. Fiquei me perguntando se havia uma maneira correta de limpá-lo, em vez de eu entrar nele e excluir todas as linhas e salvá-lo. Acho que, às vezes, os erros não são gravados imediatamente após eu limpar o log e salvá-lo.

Nota lateral: Estou tendo problemas para configurar o Postfix e estou tentando facilitar a leitura dos logs, esperando que isso possa me ajudar, em vez de ter que rolar todo o caminho.

Você pode usar:

> /var/log/mail.log

Isso truncará o log sem que você precise editar o arquivo. É também uma maneira confiável de recuperar o espaço. Às vezes, as pessoas cometem o erro de usar rm no log e recriar o nome do arquivo; se outro processo tiver o arquivo aberto, você não recuperará o espaço até que esse processo feche sua alça e você possa atrapalhar suas permissões.

Além disso, se você estiver assistindo o conteúdo do log, poderá usar o tailcomando:

tail -f /var/log/mail.log

Ctrl-C interromperá o rejeito.

Sim, existe uma maneira adequada: você não limpa os logs. Você os gira . A rotação envolve alternar a saída do log para um novo arquivo, com o mesmo nome, com os N arquivos de log anteriores mantidos sob um conjunto de N nomes de arquivos relacionados.

A maneira como a pessoa gira os logs depende de como os está gravando. Este é um ponto frequentemente esquecido. Algumas das respostas aqui mencionam, pelo menos, a menção de que alguns programas de registro mantêm um descritor de arquivo aberto para o arquivo de registro, portanto, excluir o arquivo não liberará espaço ou alternará a saída para um novo arquivo de registro.

Se o programa que está gravando o arquivo de log for multilogdo daemontoolspacote , por exemplo, você não fará nada para girar os logs - sem scripts manuais, sem crontrabalhos. Simplesmente diga multilogque a saída do log é para um diretório e ele próprio manterá um conjunto de N arquivos de log rotacionados e com tamanho máximo de tamanho nesse diretório.

Se o programa que estiver gravando os arquivos de log for svlogddo runitpacote , por outro exemplo, o mesmo se aplica. Você não faz nada além de apontar a ferramenta em um diretório. Ele próprio manterá um conjunto de N arquivos de log rotacionados e com tamanho máximo nesse diretório.

Se você estiver usando rsyslogpara gravar arquivos de log, o programa de log pode ser solicitado a parar após o arquivo atingir um determinado tamanho e executar um script . Você precisa escrever a descrição do script, para renomear o arquivo de log e excluir os arquivos de log antigos com base nas restrições de tamanho total, mas pelo menos o programa de log fechou o arquivo e interrompeu a gravação do log enquanto isso acontecia.

A syslogdmaneira antiga de girar logs, ainda esperada por programas de log como o syslog-ng e exemplificada por ferramentas como as logrotatemencionadas djangofanem outra resposta aqui, é um pouco mais casual. É executado um crontrabalho que renomeia periodicamente os arquivos de log e reinicia o daemon de log (usando o supervisor de daemon em que está sendo executado). O problema disso, é claro, é que ele não impõe um limite de tamanho geral. Em semanas lentas, é possível obter N arquivos de log diários muito pequenos, enquanto em dias de trabalho pode-se obter 1 arquivo de log muito grande que ultrapassa o limite de tamanho.

É por isso que ferramentas melhores e mais recentes gostam multiloge svlogdtêm opções de configuração de tamanho de arquivo e, na verdade, verificam os tamanhos dos arquivos de log, é claro. O mundo aprendeu que pesquisar os logs em uma programação com crontrabalhos, ou mesmo um logrotatedaemon, deixa janelas para o tamanho errado, e que o local apropriado para essas verificações é impor rigorosamente limites de tamanho definidos pelo administrador para que a pessoa os arquivos de log nunca engolem a partição em que estão, está no programa que está realmente gravando os arquivos em primeiro lugar.

Você pode usar isso também ..

truncate /opt/package/logs/*.log --size 0

Aqui todos os arquivos de log no / opt / package / logs ficarão vazios.

Sim, existe uma ferramenta para Linux chamada LogRotate .

Se o motivo de você limpar o log for liberar espaço, poderá cat / dev / null para eles, sem interromper os programas gravados nele. Nunca os apague! algum software pode reclamar ao parar de trabalhar ou ignorar completamente o log até a próxima reinicialização

cat /dev/null > /path/to/logfile

# to empty all the logs in a directory
for i in /var/log/*; do cat /dev/null > $i; done

Substituição de conteúdo curto e compatível: : > /dest/file

Mas também há uma chamada de sistema truncada (2) e a ferramenta de espaço de usuário correspondente truncateem muitos * NIX'es.

Se você deseja manter o arquivo antes de limpá-lo, você pode:

cp /var/log/mail.log /var/log/mail.log.1 && echo -n "" > /var/log/mail.log

Se você deseja pesquisar um texto ou email específico no log, pode usar o grep. Se você deseja manter alguns gráficos sobre o uso do correio, você pode usar o AWStats.

Aqui está como eu faço isso, e isso é apenas para o NGINX, você pode removê-lo para fazê-lo funcionar em todos os arquivos de log.

# Clear nginx logs.
# @usage delnginxlogs
function delnginxlogs() {
  echo "--------------- ⏲  Clearing logs... ---------------"

  # Clear logs.
  for i in /var/log/nginx/*; do cat /dev/null > $i; done

  echo "--------------- ⏲  Deleting .gz log files... ---------------"

  # Delete .gz files.
  find /var/log/nginx -type f -regex ".*\.gz$" -delete

  echo "--------------- 💯 DONE: NGINX logs cleared ... ---------------"
}

cat / dev / null> / caminho / para / arquivo de log

Funciona para mim