92 votes

Existe-t-il un moyen approprié d'effacer les journaux ?

Je me demandais s'il y avait une façon correcte d'effacer les logs en général ?

Je suis nouveau sur Ubuntu et j'essaie de configurer Postfix. Le journal en question est /var/log/mail.log . Je me demandais s'il y avait une façon correcte de l'effacer, plutôt que d'aller dans le journal, de supprimer toutes les lignes et de le sauvegarder. Je trouve que parfois les erreurs ne sont pas écrites immédiatement après avoir effacé le journal et l'avoir sauvegardé.

Remarque : j'ai des difficultés à configurer Postfix et j'essaie de faciliter la lecture des journaux en espérant que cela puisse m'aider, au lieu d'avoir à faire défiler les pages jusqu'en bas.

3 votes

Si vous voulez juste voir la fin du fichier alors queue est votre ami. tail /var/log/mail.log pour afficher les 5 dernières lignes. tail -f /var/log/mail.log pour voir toutes les lignes écrites à la fin du fichier.

0 votes

93voto

Carling Points 229

Vous pouvez utiliser :

> /var/log/mail.log

Cela permettra de tronquer le journal sans que vous ayez à modifier le fichier. C'est aussi un moyen fiable de récupérer l'espace. Parfois, les gens font l'erreur d'utiliser rm sur le journal puis de recréer le nom du fichier, si un autre processus a le fichier ouvert, vous ne récupérez pas l'espace jusqu'à ce que ce processus ferme son accès au fichier et vous pouvez perturber ses permissions.

De même, si vous observez le contenu du journal, vous pouvez utiliser la fonction tail commandement :

tail -f /var/log/mail.log

Ctrl-C brisera la queue.

2 votes

/bin/csh (commun à FreeBSD) s'en sortirait avec "Invalid null command", alors que zsh (remplacement populaire de bash ) attendrait EOF. Voir serverfault.com/a/381380/67675

0 votes

Comment puis-je le programmer ? en mettant > dans la crontab ne s'exécute pas car il se peut qu'il ne la reconnaisse pas comme une syntaxe

1 votes

Notez que sudo "> /var/log/mail.log" ne fonctionnera pas, voir stackoverflow.com/a/82278/3025740

46voto

Yasar Points 441

Vous pouvez aussi utiliser ceci..

truncate /opt/package/logs/*.log --size 0

Ici, tous les fichiers journaux du répertoire /opt/package/logs seront vides

0 votes

Je ne vois pas comment cela pourrait être mieux que les anciennes réponses.

16 votes

C'est en fait une très bonne réponse, et vraiment la seule qui réponde directement à la question de savoir s'il existe un moyen approprié de tronquer les fichiers journaux. La raison pour laquelle elle est meilleure que les autres réponses est qu'elle ne SUPPRIME pas le fichier de log, elle met à zéro le contenu correctement, donc les erreurs de permission et les fichiers de log manquants qui provoquent la panique de certains démons ne se produiront pas dans ce cas.

0 votes

Meilleure réponse, pour les raisons que hmedia1 a exposées.

31voto

teki Points 1

Oui, il y a un moyen approprié : Vous ne devez pas clair journaux du tout. Vous faire pivoter les. La rotation consiste à basculer la sortie du journal vers un nouveau fichier, sous le même nom, les N fichiers journaux précédents étant conservés sous un ensemble de N noms de fichiers connexes.

La rotation des journaux dépend de la manière dont on les écrit. C'est un point souvent négligé. Certaines des réponses ici l'abordent au moins, en mentionnant que certains programmes de journalisation conservent un descripteur de fichier ouvert pour le fichier de journalisation, de sorte que la simple suppression du fichier ne libérera pas l'espace, ni même ne basculera la sortie vers un nouveau fichier de journalisation.

Si le programme qui écrit le fichier journal est multilog de la daemontools paquet par exemple, vous ne faites rien du tout pour faire tourner les journaux - pas de scripts manuels, pas de cron emplois. Dites simplement multilog que la sortie du journal est dans un répertoire, et il maintiendra lui-même un ensemble de N fichiers journaux automatiquement tournés et de taille limitée dans ce répertoire.

Si le programme qui écrit les fichiers journaux est svlogd de la runit paquet pour un autre exemple, il en va de même. Vous ne faites rien d'autre que de pointer l'outil vers un répertoire. Il maintiendra lui-même un ensemble de N fichiers journaux automatiquement tournés et de taille limitée dans ce répertoire.

Si vous utilisez rsyslog pour écrire des fichiers journaux, puis on peut demander au programme de journalisation de s'arrêter lorsque le fichier de journalisation atteint une certaine taille et d'exécuter un script. . Vous devez écrire la partie principale du script, pour renommer le fichier journal et supprimer les anciens fichiers journaux en fonction des contraintes de taille totale, mais au moins le programme de journalisation a fermé le fichier et mis en pause l'écriture du journal pendant que cela se produit.

L'ancien syslogd la manière de faire tourner les bûches, toujours attendu par les programmes de journalisation tels que syslog-ng et comme l'illustrent des outils tels que logrotate mentionné par djangofan dans une autre réponse ici, est un peu plus aléatoire. On exécute un cron qui renomme périodiquement les fichiers journaux et redémarre le démon de journalisation (en utilisant le superviseur de démon sous lequel il est exécuté). Le problème avec cette méthode, bien sûr, est qu'elle n'impose pas de limite de taille globale. Lors des semaines lentes, on peut avoir N très petits fichiers journaux quotidiens, alors que lors des journées chargées, on peut avoir un très gros fichier journal qui dépasse largement la taille limite.

C'est pourquoi des outils plus récents et plus performants comme multilog y svlogd ont des options de configuration de la taille des fichiers et vérifient la taille des fichiers journaux eux-mêmes, bien sûr. Le monde a appris que le fait d'interroger les journaux selon un calendrier avec cron emplois, ou même un logrotate démon, laisse à Windows la possibilité de se tromper de taille, et que l'endroit approprié pour effectuer ces vérifications, et donc rigoureusement L'application des limites de taille définies par l'administrateur afin que les fichiers journaux n'engloutissent jamais la partition sur laquelle ils se trouvent se trouve dans le programme qui écrit les fichiers en premier lieu.

0 votes

Quant à rsyslog, il peut être facilement configuré de manière à s'appuyer sur des noms de fichiers décrits par un "motif" comprenant, par exemple, YEAR, MONTH et DAY. Pour cela, il suffit d'avoir un template(name="DYNmail" type="string" string="/var/log/%$YEAR%/%$MONTH%/%$DAY%/mail.log") suivie d'une directive if ($syslogfacility-text == 'mail') then -?DYNmail;TraditionalFormat . De cette façon, la rotation des journaux n'est tout simplement pas un problème, du moins lorsqu'un seul fichier par jour est suffisant. Pour les très gros volumes de logs (nécessitant plusieurs rotations par jour), il y a $HOUR également.

12voto

djangofan Points 4152

Oui, il existe un outil pour linux appelé LogRotate .

9 votes

Petite correction : il ne s'agit pas d'un service, mais d'un outil, généralement exécuté par un service cron.

11voto

Elvis Points 201

Si la raison pour laquelle vous effacez le journal est de libérer de l'espace, vous pouvez cat /dev/null vers eux, sans interrompre les programmes qui y écrivent. Ne les supprimez jamais ! Certains logiciels pourraient se plaindre en arrêtant de fonctionner ou en ignorant complètement le journal jusqu'au prochain redémarrage.

cat /dev/null > /path/to/logfile

# to empty all the logs in a directory
for i in /var/log/*; do cat /dev/null > $i; done

6 votes

Pour effacer les fichiers journaux de manière récursive : for i in $(find /var/log -type f); do cat /dev/null > $i; done

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X