☰

Upstart não reabrindo arquivos de log no logrotation

tag-icon • tag-icon upstart init logrotate
Upstart não reabrindo arquivos de log no logrotation

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

Então, diariamente, os arquivos de log são rotacionados usando o script logrotation que vem com o 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 para o iniciante fechar e reabrir os arquivos, deixando o processo inicial gravando em 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 dos meus próprios serviços para outros arquivos de log, mas o problema ainda estaria presente nos processos do sistema. Além disso, preferiria não ter que construir mais infraestrutura do que preciso.

Responder1

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 pode ou (não tem permissão) para alterar a configuração de logrotate existente por causa de outros arquivos de log que não sofrem e a configuração existente funciona 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 tiver permissão para alterar a configuração do host os logrotate ou adicionar ao cron.daily do sistema operacional host, sua terceira opção é alterar os scripts ou programas para verificar se o arquivo existe antes de gravá-lo no arquivo. b) Outra maneira é um pouco do ponto 2 acima, que é mover seus arquivos de log para outro lugar e dentro do seu script ou programa, executar o comando logrotate específico para o arquivo de log desse programa.

O ponto 3b acima é mais complicado, mas mais elegante, e é o que eu uso na maioria das vezes, pois significa que o programa é autossuficiente e autogerenciado e não precisa dos trabalhos do sistema operacional 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 Python para seus programas, poderá verificar como este programa o utiliza para autogerenciar seus arquivos de log. http://bazaar.launchpad.net/~ferncasado/keep.awake/trunk/files/head:/v4/

Responder2

Acontece que este é um problema conhecido e obilhetepermanece aberto enquanto digito isso.

A coisa certa a fazer é, provavelmente, apenas remover /etc/logrotate.d/upstarttudo e girar os arquivos dos serviços individuais individualmente. Como 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 umdaemondeveria estar enviando para esses dois canais. Exceto, talvez, logo no início.

Nos sistemas que estou gerenciando, três serviços são executados pelo iniciante: php5.6-fpm, php7.1-fpme 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 girado - e isso causa esse ruído, porque gera alguma inanidade na inicialização.

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

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

Para que o procedimento acima funcione, certifique-se denãouse o sharedscriptsverbo ali - meu scriptlet depende do fato de que o caminho real para o arquivo será passado para ele como o primeiro argumento ( $1).

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

informação relacionada