rsyslog com logrotate: recarregar rsyslog vs copytruncate

Estou trabalhando no Ubuntu 14 com o utilitário rsyslog e logrotate padrão.

Na /etc/logrotate.d/rsyslogconfiguração padrão do rsyslog logrotate , vejo o seguinte:

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

Pelo que entendi, é recomendável usar copytruncate em todos os cenários de rotação de log, pois não move o log atual, mas trunca o log para que qualquer processo com um manipulador de arquivo aberto possa continuar gravando nele.

Então, como é que a configuração padrão usando o recurso de recarga rsyslog?

Para responder sua pergunta, primeiro você precisa entender as diferentes vantagens de recarregar e copiar truncado:

• recarregar : o arquivo de log antigo é renomeado e o processo de gravação nesse log é notificado (via sinal Unix) para recriar seu arquivo de log. Esse é o método de sobrecarga mais rápido / mais baixo: as operações de renomeação / movimentação são muito rápidas e têm um tempo de execução constante. Além disso, é uma operação quase atômica: isso significa que (quase) nenhuma entrada de log será perdida durante a movimentação / recarregamento. Por outro lado, você precisa de um processo capaz de recarregar e reabrir seu arquivo de log. O Rsyslog é um processo desse tipo; portanto, a configuração padrão de logrotate usa o método reload. O uso desse modo com o rsyslog é altamente recomendado pelo rsyslog upstream.
• copytruncate : o arquivo de log antigo é copiado em um arquivo e, em seguida, é truncado para "excluir" as linhas de log antigas. Enquanto a operação truncada é muito rápida, a cópia pode ser bastante longa (dependendo do tamanho do seu arquivo de log). Além disso, algumas entradas de log podem ser perdidas durante o tempo entre a operação de cópia (lembre-se, pode ser lenta) e a truncada. Por esses motivos, copytruncate não é usado por padrão para serviços capazes de recarregar e recriar seus arquivos de log. Por outro lado, se um servidor não for capaz de recarregar / recriar arquivos de log, copytruncate é sua aposta mais segura. Em outras palavras, ele não requer nenhum suporte no nível de serviço. O projeto upstream do rsyslog desaconselha fortemente o uso desse modo.

Falando como autor do rsyslog, copytruncate é realmente uma escolha muito, muito, muito ruim. É inerentemente atrevido e usá-lo é quase uma garantia de que você perderá dados de log. Quanto mais frequentemente o arquivo for gravado, mais você perderá. E isso não é apenas parte da última linha, mas pode ser várias centenas, dependendo do momento exato e do estado do sistema no momento em que a rotação acontece.

Quando o arquivo é movido e um novo inode (arquivo) é criado, o rsyslog mantém o controle do arquivo anterior e conclui o processamento. Portanto, você não tem nenhuma perda neste caso. Garantido (exceto se você desmontar o sistema de arquivos ...).

Sobre "reopenOnTruncate": Eu pessoalmente vi o reopenOnTruncate sendo atrevido em outros aspectos também, especialmente no NFS e similares. Algum tempo atrás, removi totalmente essa funcionalidade, mas mais tarde fui convencido a incorporar funcionalidades semelhantes. Ele permanecerá "experimental" provavelmente para sempre, pois eu realmente sei que as pessoas enfrentam problemas em sistemas muito carregados. "copytruncate" simplesmente não é um modo decente para trabalhar com arquivos de log.

Atualmente, trabalho na refatoração de imfile (ETA 8.34 ou 8.35). A versão refatorada provavelmente poderá impedir o reenvio acidental devido à corrida da API, mas também não pode se proteger contra a perda de dados - porque isso é conceitualmente impossível.

Isso depende completamente de como o processo está gravando logs.
copytruncatesó funciona, se as mensagens de log são anexados ao arquivo (por exemplo whatever >> logfile.
E não quando ele está redirecionando a saída (por exemplo whatever > logfile).

Desde a versão 8.16, o rsyslog possui a opção imfile reopenOnTruncateque lida com problemas de cópia de erro.

Para o rsyslog especificamente, provavelmente faz mais sentido deixar as coisas como estão.

O motivo básico é que o rsyslog tem filas internas que podem ser usadas nos casos em que seu identificador de saída se torna indisponível.

A recarga a) fará com que o rsyslog recrie seu próprio arquivo de log eb) faça com que quaisquer eventos na fila sejam liberados para o arquivo na criação.

Pode ser que o copytruncate não cause danos (embora eu esteja preocupado com truncamento de linhas parcialmente escritas), mas eu tenderia a pensar que copiar / excluir / recarregar é 'mais seguro' do ponto de vista da integridade.

Conforme mencionado por @ faker , como o rsyslog pode lidar com a situação em que seu arquivo se torna indisponível, não há um motivo convincente para usar copytruncate.

E, como mencionado por @ SelivanovPavel , o rsyslog na verdade requer uma configuração específica para lidar com a cópia truncada corretamente.

Portanto, apenas porque o uso da reloadabordagem exige menos desvio da configuração padrão, eu a manteria.