Solution 1 :
Vous pouvez utiliser :
> /var/log/mail.log
Cela tronquera le journal sans que vous ayez à modifier le fichier. C'est aussi un moyen fiable de récupérer de l'espace. Parfois, les gens font l'erreur d'utiliser rm sur le journal puis de recréer le nom de fichier, si un autre processus a le fichier ouvert, vous ne récupérez pas l'espace jusqu'à ce que ce processus ferme son contrôle et vous pouvez gâcher ses autorisations.
Aussi, si vous regardez le contenu du journal, vous aimerez peut-être utiliser le tail commande :
tail -f /var/log/mail.log
Ctrl-C cassera la queue.
Solution 2 :
Oui, il existe une méthode appropriée :vous n'effacez pas journaux du tout. Vous tournez leur. La rotation implique de 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 associés.
La rotation des journaux dépend de la façon dont on les écrit en premier lieu. 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 journal, donc la simple suppression du fichier ne libérera pas d'espace, ni même basculera la sortie vers un nouveau fichier journal.
Si le programme qui écrit le fichier journal est multilog du daemontools package, par exemple, alors vous ne faites rien du tout pour faire pivoter les journaux — pas de scripts manuels, pas de cron travaux. Dites simplement multilog cette sortie de journal est dans un répertoire, et il conservera lui-même un ensemble de N fichiers journaux automatiquement pivotés et limités en taille dans ce répertoire.
Si le programme qui écrit les fichiers journaux est svlogd du runit package, pour un autre exemple, alors la même chose s'applique. Vous ne faites rien du tout à part pointer l'outil vers un répertoire. Il maintiendra lui-même un ensemble de N fichiers journaux automatiquement pivotés et limités en taille dans ce répertoire.
Si vous utilisez rsyslog pour écrire des fichiers journaux, le programme de journalisation peut être invité à s'arrêter une fois que le fichier journal a atteint une certaine taille et à exécuter un script. Vous devez écrire la viande 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 suspendu l'écriture du journal pendant que cela se produit.
L'ancien syslogd manière de faire tourner les journaux, toujours attendue par les programmes de journalisation tels que syslog-ng et illustrée par 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 du démon sous lequel il s'exécute). Le problème avec cela, bien sûr, c'est qu'il n'impose pas de limite de taille globale. Les semaines lentes, on peut obtenir N très petits fichiers journaux quotidiens, tandis que les jours de pointe, on peut obtenir 1 très gros fichier journal qui dépasse largement la limite de taille.
C'est pourquoi des outils plus récents et meilleurs comme multilog et svlogd avoir des options de configuration de taille de fichier et vérifier eux-mêmes la taille des fichiers journaux, bien sûr. Le monde a appris que l'interrogation des journaux selon un calendrier avec cron emplois, ou même un logrotate démon, laisse les fenêtres pour que la taille soit erronée, et que le bon endroit pour faire ces vérifications, et donc rigoureusement appliquer des plafonds de taille définis par l'administrateur afin que ses fichiers journaux n'avalent jamais la partition sur laquelle ils se trouvent, se trouve dans le programme qui écrit réellement les fichiers en premier lieu.
Solution 3 :
Vous pouvez aussi l'utiliser..
truncate /opt/package/logs/*.log --size 0
Ici, tous les fichiers journaux dans /opt/package/logs deviendront vides.
Solution 4 :
Oui, il existe un outil pour Linux appelé LogRotate .
Solution 5 :
Si la raison pour laquelle vous effacez le journal est de libérer de l'espace, vous pouvez lui envoyer un cat /dev/null, sans interrompre les programmes qui y écrivent. Ne les supprimez jamais ! certains logiciels peuvent se plaindre en cessant 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