Iniciante não reabrindo arquivos de log na rotação de log

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

Diariamente, os arquivos de log são rotacionados usando o script de rotação de log que acompanha o 12.04 LTS:

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

O problema é que, enquanto o logrotate move os arquivos, ele não parece sinalizar para iniciar novamente para 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 lá para os processos do sistema. Também prefiro não ter que construir mais infraestrutura do que o que eu preciso.

Eu acredito que você tem 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) alterar a configuração existente de rotação de log devido a 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-o ao cron.daily.

3. a) Se você não tem 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. 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, execute 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 é auto-suficiente e autogerenciado e não precisa das tarefas 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 o Python para seus programas, verifique como este programa o utiliza para gerenciar automaticamente seus arquivos de log. http://bazaar.launchpad.net/~ferncasado/keep.awake/trunk/files/head:/v4/

Acontece que este é um problema conhecido e o ticket permanece aberto enquanto eu digito isso.

A coisa certa a fazer é, provavelmente, remover /etc/logrotate.d/upstartcompletamente 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 um daemon deve ser transmitido para esses dois canais. Exceto, talvez, na própria inicialização.

Nos sistemas Estou gestão, 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 algumas vezes o fpm é reiniciado devido à /var/log/php5.6-fpm.logrotação do arquivo de log principal ( ) - e causa esse ruído, porque gera alguma inanidade na inicialização.

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

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

Para que o trabalho acima funcione, certifique-se de não usar o sharedscriptsverbo - meu scriptlet se baseia no fato de que o caminho real para o arquivo será passado como o primeiro argumento ( $1).

(O redirecionamento para /dev/nullé útil, porque o servicecomando é barulhento - e você não deseja que esse ruído seja enviado por e-mail pelo cron. Observe que eu não estou redirecionando stderrapenas stdoutpara lá - se houver um problema, você ainda receberá seu e-mail sobre isso.)