Como registrar corretamente os logs de serviço gerenciados pelo systemd via `file:` config

Aug 19 2020

Eu tenho um serviço gerenciado pelo systemd que tem a seguinte configuração do systemd dizendo ao systemd para gravar os logs em um arquivo diretamente (sem syslog ou qualquer coisa)

StandardOutput=file:/var/log/foo/my.log

Eu tenho uma regra de logrotate

/var/log/foo/*.log
{
        rotate 31
        daily
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
}

O que está acontecendo é que os logs estão sendo girados, mas o serviço ainda está gravando no arquivo girado antigo e o novo arquivo de log permanece vazio.

Eu tenho uma configuração de trabalho semelhante em que o serviço grava no syslog. Esse funciona bem porque a configuração do logrotate tem

postrotate
                invoke-rc.d rsyslog rotate > /dev/null

, que notifica o syslog que seu log foi girado.

O problema é que, no meu caso problemático, o log está indo diretamente para o arquivo, então não sei se (ou qual deles) preciso enviar um sinal semelhante ao systemd ou ao processo de serviço real.

Encontrei a copytruncateopção no logrotate que tenho certeza que corrigirá meu problema, mas estou tendo a sensação de que essa não é a maneira ideal de fazer isso, caso contrário, copytruncateseria o comportamento padrão do logrotate.

Como eu resolvo este problema? eu preciso enviar algum sinal para o systemd? eu preciso enviar algum sinal para o processo de serviço? eu tenho que usar copytruncateno logrotate em vez disso?
Se for importante, o serviço é um processo java usando logback para gravar em stdout

Respostas

eleventyone Aug 18 2020 at 22:32

copytruncateé a resposta certa neste caso. Não é o padrão porque é menos comum precisar dele, porque você teria um daemon adequado que pode sinalizar para reabrir o arquivo de log.

A alternativa é reiniciar o serviço no script pós-rotação, mas isso pode não ser conveniente ou desejável.