J'ai accidentellement supprimé le /var/log/mailfichier. Jusque-là, je pouvais le surveiller en utilisant des trucs postfix. Maintenant, il semble que Postfix n'envoie pas ses journaux à /var/log/mail, car le fichier n'est pas mis à jour avec de nouveaux messages de journal.
10
Même après avoir créé un fichier vide
vous devez redémarrer le syslog
puis c'est le gain de journalisation :)
la source
Il s'agit d'un bogue dans syslog, mais illustre un problème courant lorsque l'on supprime un fichier alors qu'il est ouvert par un programme. Lorsque vous effectuez un "rm", vous supprimez une entrée de répertoire, mais vous ne supprimez PAS le fichier sous-jacent. Le système d'exploitation conserve un nombre de références au fichier et ne supprimera pas réellement les données du fichier sous-jacent jusqu'à ce que le nombre de références atteigne zéro. Dans le cas d'un fichier moyen, le nombre de références du fichier non ouvert est un (l'entrée de répertoire). Lorsque le fichier est ouvert, le nombre est incrémenté à deux. Si un deuxième programme ouvre le même fichier, le nombre sera incrémenté à trois. Si l'entrée de répertoire est maintenant supprimée, le nombre est décrémenté à deux - ce qui signifie que le fichier est anomyme (n'a pas de nom),
Lorsque vous supprimez / var / log / mail, l'enregistreur système a toujours le fichier ouvert pour l'écriture. Si vous créez un nouveau / var / log / mail, il pointera vers un fichier différent de celui que l'enregistreur système écrit actuellement. La seule façon de rendre tout cohérent est de redémarrer l'enregistreur système. Lorsque l'enregistreur système d'origine se termine, tous les fichiers qui lui sont associés sont fermés, y compris le journal de messagerie anonyme dont vous avez supprimé l'entrée de répertoire. Lorsque vous redémarrez l'enregistreur système, il rouvrira / var / log / mail lorsqu'il aura besoin d'écrire un message de journal et le gardera ensuite ouvert.
Ceci est également souvent découvert lorsqu'un programme en cours d'exécution remplit tout un disque avec des données de fichier; l'utilisateur supprime le très gros fichier, mais l'espace disque n'est pas libéré, car le fichier existe toujours et occupe de l'espace disque, mais l'entrée de répertoire a été supprimée. À la fin du programme (soit parce que l'utilisateur l'a tué, soit parce qu'il s'est arrêté lui-même), l'espace disque sera récupéré car le nombre de références sur le fichier sera passé à zéro.
Ce que l'enregistreur peut faire pour éviter cela, c'est d'abord écrire le message du journal, vérifier si l'entrée du répertoire du fichier journal existe, et si elle n'existe pas, fermer le fichier journal d'origine, en ouvrir un nouveau, puis réécrire le message - pour que le message ne soit pas perdu. Mais pour faire tout cela, il faudrait beaucoup plus de complexité que l'enregistreur système devrait avoir - pour chaque message qu'il écrit prendra un peu plus de temps à écrire en raison de la vérification supplémentaire du répertoire - qui réussira chaque fois que le fichier aura PAS été supprimé.
Pour mieux comprendre tout ce qui précède, la commande suivante est instructive, car elle décrit l'appel système qui effectue la suppression de l'entrée de répertoire et le décrément de référence: "man 3 unlink"
la source
Ce n'est pas le problème sur CentOS 7. Quelqu'un a pensé que ce serait une bonne idée d'avoir les journaux de messagerie postfix pour passer par le journal. Si vous voulez voir les journaux de postfix:
(pour voir le journal entier)
(pour suivre le journal)
Vous pouvez également avoir besoin dans le fichier main.cf pour postfix
la source
journalctl --vacuum-time=1dfwiw versions plus récentes du journal de postfix
/var/log/mail.loget j'ai également dû exécutersudo chmod a+w /var/log/mail*etservice postfix restartrécupérer mes journaux de postfix après les avoir supprimésla source