Démarrage ne rouvre pas les fichiers journaux sur logrotation

Nous utilisons upstart pour gérer nos services sur nos serveurs Ubuntu. Ils produisent des journaux qui sont déconnectés de /var/log/upstart/SERVICE_NAME.log

Puis quotidiennement, les fichiers journaux sont tournés à l'aide du script logrotation fourni avec 12.04 LTS:

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

Le problème est que, tandis que logrotate déplace les fichiers, il ne semble pas signaler à upstart de fermer et rouvrir les fichiers, laissant le processus upstart écrit dans un PID de suppression.

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

Évidemment, je pouvais rediriger la sortie de mes propres services vers d'autres fichiers journaux, mais le problème serait toujours là pour les processus système. De plus, je préfère ne pas avoir à construire plus d'infrastructures que ce dont j'ai besoin.

upstart init logrotate

— Andrew Newdigate
source

Je viens également de rencontrer cela. C'est très étrange que nous ne l'ayons pas remarqué auparavant, ce qui me fait penser que cela pourrait être récent.

— pwaller

Une mise à jour pour ceci? Voir exactement le même problème le 14.04. C'est à cause de la nocreatedirective, je ne sais pas pourquoi quelqu'un utiliserait cette directive, en particulier pour les services qui pourraient potentiellement écrire beaucoup de sortie

— rynop

Vivre également cela.

— Ztyx

J'ai trouvé ce bug

— Lety

Réponses:

Je crois que vous avez 3 options.

Vous modifiez la configuration existante en ajoutant "copytruncate"

/var/log/upstart/*.log { copytruncate daily missingok rotate 7 compress notifempty nocreate }
Si vous ne pouvez pas (ou n'êtes pas autorisé) à modifier la configuration logrotate existante en raison d'autres fichiers journaux qui ne souffrent pas et que la configuration existante fonctionne pour eux, déplacez vos fichiers "SERVICE_NAME.log" dans un nouveau dossier sous / var / log si vous le souhaitez, créez une nouvelle configuration avec le "copytruncate" et ajoutez-la au cron.daily.
a) Si vous n'êtes pas autorisé à modifier la configuration logrotate du système d'exploitation hôte ou à l'ajouter à cron.daily du système d'exploitation hôte, votre troisième option consiste à modifier les scripts ou les programmes pour vérifier que le fichier existe avant d'écrire dans le fichier. b) Une autre façon est un peu du point 2 ci-dessus qui consiste à déplacer vos fichiers journaux ailleurs et dans votre script ou programme, exécutez la commande logrotate spécifique au fichier journal de ce programme.

Le point 3b ci-dessus est plus délicat mais plus élégant et c'est ce que j'utilise la plupart du temps car cela signifie que le programme est autosuffisant et autogéré et n'a pas besoin des travaux du système d'exploitation pour le garder.

Pour savoir comment exécuter manuellement logrotate et l'ajouter à votre programme ou script, tapez simplement:

man logrotate

logrotate --help

Si vous utilisez Python pour vos programmes, vous pouvez vérifier comment ce programme l'utilise pour gérer lui-même ses fichiers journaux. http://bazaar.launchpad.net/~ferncasado/keep.awake/trunk/files/head:/v4/

— DanglingPointer
source

Il s'avère que c'est un problème connu et le ticket reste ouvert pendant que je tape ceci.

La bonne chose à faire est probablement de supprimer le /etc/logrotate.d/upstarttout et de faire pivoter les fichiers des services individuels individuellement. Parce que le répertoire ( /var/log/upstart/) ne contient que le stdout / stderr des différents services - et aucun service destiné à s'exécuter en tant que démon ne devrait être sorti sur ces deux canaux. Sauf, peut-être, au tout début.

Sur les systèmes je gère, trois services sont gérés par arriviste: php5.6-fpm, php7.1-fpmet acpid. Aucun des trois journaux n'est actif, mais parfois le fpm est redémarré en raison de la /var/log/php5.6-fpm.logrotation de son fichier journal principal ( ) - et il provoque ce bruit, car il génère une certaine folie au démarrage.

Si vous persistez à faire tourner ces fichiers de toute façon, vous pouvez vous fier au fait que leurs noms correspondent aux noms des services et utiliser le postrotatescript suivant :

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

Pour que ce qui précède fonctionne, assurez-vous de ne pas utiliser le ~~sharedscripts~~verbe là-dedans - mon scriptlet repose sur le fait, le chemin réel vers le fichier lui sera transmis comme premier argument ( $1).

(La redirection vers /dev/nullest utile, car service-la commande est bruyante - et vous ne voulez pas que ce bruit vous soit envoyé par cron. Notez que je ne redirige pas stderrlà, seulement stdout- s'il y a un problème, vous Je vais toujours recevoir votre e-mail à ce sujet.)

— Mikhail T.
source