Upstart não reabrindo os arquivos de log no logrotation

Question

Usamos o upstart para gerenciar nossos serviços em nossos servidores Ubuntu. Eles produzem logs que são desconectados para /var/log/upstart/SERVICE_NAME.log

Então diariamente, os arquivos de log são rotacionados usando o script logrotation que vem com 12.04 LTS:

/var/log/upstart/*.log {
        daily
        missingok
        rotate 7
        compress
        notifempty
        nocreate
}

O problema é que, embora o logrotate mova os arquivos, ele não parece sinalizar ao upstart para fechar e reabrir os arquivos, deixando o processo de inicialização para um PID de exclusão.

init          1       root    8w      REG              202,1        64       2431 /var/log/upstart/dbus.log.1 (deleted)
init          1       root   13w      REG              202,1        95       2507 /var/log/upstart/acpid.log.1 (deleted)
init          1       root   14w      REG              202,1       127      17377 /var/log/upstart/whoopsie.log.1 (deleted)
init          1       root   36w      REG              202,1       122       6747 /var/log/upstart/SERVICE_NAME.log.1 (deleted)
init          1       root   37w      REG              202,1        30       6762 

Obviamente, eu poderia redirecionar a saída de meus próprios serviços para outros arquivos de log, mas o problema ainda estaria lá para os processos do sistema. Também prefiro não ter que construir mais infra-estrutura do que o necessário.

    

Answer 1

Eu acredito que você tenha 3 opções.

1. Você modifica a configuração existente adicionando "copytruncate"

   /var/log/upstart/*.log { copytruncate daily missingok rotate 7 compress notifempty nocreate }

2. Se você não puder ou (não for permitido) alterar a configuração do logrotate existente devido a outros arquivos de log que não sofrem e a configuração existente funcionar para eles, mova seus arquivos "SERVICE_NAME.log" para uma nova pasta em / var / log, se desejar, crie uma nova configuração com o "copytruncate" e adicione-a ao cron.daily.

3. a) Se você não tem permissão para alterar o host os logrotate config ou adicionar ao cron.daily do sistema operacional host, então sua terceira opção é alterar os scripts ou programas para verificar se o arquivo existe antes escrevendo para o arquivo. b) Outra maneira é um pouco do ponto 2 acima, que é mover seus arquivos de log para outro lugar e dentro de seu script ou programa, executar o comando logrotate específico para o arquivo de log do programa.

O ponto 3b acima é mais complicado, mas mais elegante e é o que eu uso na maior parte do tempo, pois significa que o programa é autossuficiente e autogerenciado e não precisa dos serviços do SO para cuidar dele.

Para descobrir como executar manualmente o logrotate e adicioná-lo ao seu programa ou script, basta digitar:

man logrotate

ou

logrotate --help

Se você estiver usando o Python para seus programas, poderá verificar como esse programa o utiliza para autogerenciar seus arquivos de log. link

    

Answer 2

Acontece que este é um problema conhecido e o tíquete permanece aberto enquanto eu digite isso.

A coisa certa a fazer é, provavelmente, remover apenas o /etc/logrotate.d/upstart e girar os arquivos dos serviços individuais individualmente. Porque o diretório ( /var/log/upstart/ ) contém apenas o stdout / stderr dos vários serviços - e nenhum serviço destinado a ser executado como um daemon deve ser enviado para esses dois canais. Exceto, talvez, na própria inicialização.

Nos sistemas que estou gerenciando, três serviços são executados por upstart: php5.6-fpm , php7.1-fpm e acpid . Nenhum dos três logs está ativo, mas às vezes o fpm é reiniciado devido ao seu arquivo de log principal ( /var/log/php5.6-fpm.log ) ser rotacionado - e causa esse ruído, porque ele gera alguma inanidade na inicialização.

Se você insistir em rotacionar esses arquivos de qualquer maneira, poderá confiar no fato de que seus nomes correspondem aos nomes dos serviços e usar o seguinte script postrotate :

    postrotate
            service=${1##*/}
            service=${service%.log*}
            service $service restart > /dev/null
    endscript

Para o acima funcionar, certifique-se de não usar o verbo sharedscripts lá - meu scriptlet se baseia no fato, o caminho real para o arquivo será passado para ele como o primeiro argumento ( ).

(O redirecionamento para /dev/null é útil, porque service -command é barulhento - e você não quer que esse ruído seja enviado por você pelo cron. Observe que não estou redirecionando stderr lá, apenas stdout - se houver algum problema, você ainda receberá seu e-mail sobre isso.