Comment correctement journaliser les journaux de service gérés par systemd via `file:` config

Aug 19 2020

J'ai un service géré par systemd qui a la configuration systemd suivante indiquant à systemd d'écrire les journaux directement dans un fichier (pas de syslog ou quoi que ce soit)

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

J'ai une règle logrotate

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

Ce qui se passe, c'est que les journaux sont en cours de rotation, mais le service écrit toujours dans l'ancien fichier pivoté et le nouveau fichier journal reste vide.

J'ai une configuration de travail similaire où le service écrit à la place dans syslog. Celui-là fonctionne très bien car la configuration logrotate a

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

, qui notifie à syslog que son journal a été tourné.

Le problème est que dans mon cas problématique, le journal va directement au fichier, donc je ne sais pas si (ou lequel) j'ai besoin d'envoyer un signal similaire à systemd ou au processus de service réel.

J'ai trouvé l' copytruncateoption dans logrotate qui, j'en suis sûr, résoudra mon problème, mais j'ai l'impression que ce n'est pas la façon idéale de le faire, sinon ce copytruncateserait le comportement par défaut de logrotate.

Comment résoudre ce problème? dois-je envoyer un signal à systemd? dois-je envoyer un signal au processus de service? dois-je utiliser copytruncateà la place dans logrotate?
Si cela compte, le service est un processus java utilisant logback pour écrire sur stdout

Réponses

eleventyone Aug 18 2020 at 22:32

copytruncateest la bonne réponse dans ce cas. Ce n'est pas la valeur par défaut car il est moins courant d'en avoir besoin, car vous auriez un démon approprié que vous pouvez signaler pour rouvrir le fichier journal.

L'alternative consiste à redémarrer le service dans le script de post-rotation, mais cela peut ne pas être pratique ou souhaitable.