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.
nocreate
directive, je ne sais pas pourquoi quelqu'un utiliserait cette directive, en particulier pour les services qui pourraient potentiellement écrire beaucoup de sortieRé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:
ou
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/
la 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/upstart
tout 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-fpm
etacpid
. Aucun des trois journaux n'est actif, mais parfois le fpm est redémarré en raison de la/var/log/php5.6-fpm.log
rotation 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
postrotate
script suivant :Pour que ce qui précède fonctionne, assurez-vous de ne pas utiliser le
verbe là-dedans - mon scriptlet repose sur le fait, le chemin réel vers le fichier lui sera transmis comme premier argument (sharedscripts
$1
).(La redirection vers
/dev/null
est utile, carservice
-la commande est bruyante - et vous ne voulez pas que ce bruit vous soit envoyé par cron. Notez que je ne redirige passtderr
là, seulementstdout
- s'il y a un problème, vous Je vais toujours recevoir votre e-mail à ce sujet.)la source