Supprimer tout / var / log?


26

Puis-je tout supprimer /var/log? Ou dois-je uniquement supprimer des fichiers (récursivement) dans /var/logmais laisser des dossiers?

Quelqu'un at-il une bonne rmligne de commande? (Mes compétences en administration me rendent nerveux.)

Remarque: j'utilise Debian. Je ne sais pas quelle version.


3
La suppression des fichiers journaux est une mauvaise idée (vous devrez également trouver chaque processus en cours d'exécution qui a son propre fichier journal et le "tuer -HUP", un redémarrage en douceur qui entraînera la recréation des fichiers journaux nécessaires par le programme). Je vous déconseille fortement de supprimer les fichiers journaux, comptez sur des utilitaires comme logrotate pour gérer automatiquement le contenu de / var / log (cela fait des trucs comme HUP les processus). Si vous le permettez, j'aimerais aborder cela sous un angle différent. Quel problème essayez-vous de résoudre qui vous a amené à y réfléchir?
Twirrim

Réponses:


22

Au lieu de supprimer les fichiers, vous devez les faire pivoter, par exemple en utilisant logrotate.

Vous ne savez jamais quand vous aurez réellement besoin des journaux d'il y a quelque temps, il est donc préférable de les archiver (jusqu'à un âge raisonnable, par exemple 3 mois).

logrotate peut compresser vos anciens fichiers journaux afin qu'ils n'occupent pas beaucoup d'espace disque.


3
logrotate peut également supprimer les fichiers les plus anciens.
Kevin M

8
Eh bien, à mon humble avis, la suppression de tous les journaux peut être parfaitement logique dans certains cas. Par exemple, je veux créer une image Virtial Machine à utiliser pour de nouveaux déploiements. Inutile de dire que je voudrais que ce soit un système vraiment propre sans aucun journal, historique, cache, etc. enregistré.
Ivan

2
Désolé, mais regarder des fichiers journaux vieux de trois mois est de l'archéologie. Si vous collectez des journaux pour identifier les problèmes, évaluez-les rapidement.
contre-mode

4
@countermode Vous n'êtes jamais d'humeur nostalgique? Comme regarder les fichiers journaux de 3 mois en pensant aux bons vieux temps?
Broco

OK, je vois la commande. Comment l'utiliser? l'homme logrotate dit de l'utiliser en cron. Je suppose qu'avec l'option -f?
SDsolar

17

Si vous supprimez tout dans / var / log, vous vous retrouverez très probablement avec des tonnes de messages d'erreur en très peu de temps, car il y a des dossiers qui devraient exister (par exemple exim4, apache2, apt, cups, mysql, samba et plus). Le plus: certains services ou applications ne créeront pas leurs fichiers journaux s'ils n'existent pas. Ils s'attendent à ce qu'au moins un fichier vide soit présent. La réponse directe à votre question est donc "ne faites pas ça !!!" .

Comme l'a souligné joschi, il n'y a aucune raison de le faire. J'ai des serveurs Debian en cours d'exécution qui n'ont pas eu un seul fichier journal supprimé depuis des années.


Je ne m'en rendais pas compte. bon à savoir. +1 + a changé mon acceptation.

1
Je viens de faire ça. Souhait! J'avais lu cette réponse plus tôt
VarunAgw

Il existe des raisons valables pour supprimer les fichiers journaux, à mon humble avis. Par exemple, vous exportez une machine virtuelle pour une utilisation par d'autres, mais vous ne voulez pas que l'image de la machine virtuelle contienne des détails de tout ce qui s'est passé avant l'exportation.
a3nm

15

Supprimer tous les fichiers:

find /var/log -type f -delete

Supprimer tous les fichiers .gz et tournés

find /var/log -type f -regex ".*\.gz$"
find /var/log -type f -regex ".*\.[0-9]$"

Essayez d'exécuter la commande sans "-delete" pour la tester.


J'ai trouvé cela utile pour effacer les fichiers journaux d'une boîte Vagrant avant de les empaqueter.
Rudolf Vavruch

10

Je clone des machines virtuelles à partir d'un maître. Il est parfaitement logique d'effacer le journal sur le maître afin que lorsque vous démarrez les clones, vous n'obtiendrez pas le journal du maître. J'ai fait dans tcsh:

cd /var/log
foreach ii ( `find . -type f` )
foreach? cp /dev/null $ii
foreach? end

qui efface les journaux mais conserve les fichiers.


Cela devrait être limité à un cas d'utilisation comme vous le décrivez.
Sven

4
En bash: trouver / var / log / -type f -exec cp / dev / null {} \;
gerard

7

Nettoyage de tous les journaux sur un système Linux sans supprimer les fichiers:

for CLEAN in $(find /var/log/ -type f)
do
    cp /dev/null  $CLEAN
done

Samba ( /var/www/samba) crée des noms de fichiers journaux avec des adresses IP, vous pouvez les supprimer:

for CLEAN in $(find /var/log/samba -type f)
do
    rm -rf $CLEAN
done

2
Script utile.
Anmol Singh Jaggi

Vous pouvez échanger cp /dev/null $CLEANpar > $CLEAN.
ThoriumBR

2

Vous pouvez utiliser l'option ctime pour retrouver d'anciens fichiers ... par exemple:

find -ctime +30

Comme bindbn l'explique, essayez d'abord de rechercher les fichiers de récupération et après avoir utilisé l'option supprimer: D


2

/var/loga souvent des autorisations de drwxrwxr-x, n'est donc pas accessible en écriture à moins que l'utilisateur ne soit root ou n'appartienne à un groupe privilégié. Cela signifie que de nouveaux fichiers journaux ne peuvent pas être créés par des utilisateurs non privilégiés.

Les applications qui s'attendent à se connecter à un point à l'intérieur /var/logtoucheront souvent un fichier existant quelque part dans la /var/loghiérarchie pendant le temps d'installation (ce qui se produit souvent avec des privilèges élevés), et le feront chmodéventuellement chownà des autorisations appropriées pour les utilisateurs non privilégiés qui seront en utilisant l'application.

Les journaux Apache, par exemple, sont généralement écrits par nobody, qui est un utilisateur avec le moins de privilèges possible pour qu'Apache puisse faire son travail sans mettre le système en danger indu. Mais même une application plus courante s'attend souvent à pouvoir écrire dans un fichier journal /var/log.

Que se passe-t-il donc si le fichier journal et le chemin d'accès au fichier journal n'existent pas? Cela dépend entièrement de l'application. Certaines applications ignoreront tranquillement la journalisation. D'autres créeront de nombreux avertissements. Et d'autres vont simplement renflouer. Il n'y a pas de règle stricte; cela dépend de la vigilance du développeur de l'application, ainsi que de la mesure dans laquelle le développeur considère sa capacité à se connecter. Au mieux, l'application tentera d'écrire, ou peut-être de créer puis d'écrire dans un fichier journal à une destination à l'intérieur /var/log, et se trouvera incapable de le faire car elle est exécutée par un utilisateur qui n'a pas les privilèges pour écrire dans cette partie du système de fichiers.

Donc, la réponse courte est non, ne supprimez pas tout /var/log- cela casse les utilisateurs du contrat avec des privilèges suffisants pour faire de telles choses avec les applications qui s'exécutent sur leur système, et provoquera du bruit, un échec silencieux de la journalisation, et une rupture totale.

L'action appropriée à entreprendre est de configurer logrotateavec les fichiers de configuration appropriés. La rotation est généralement associée à une tâche cron. La rotation peut être basée sur un intervalle, ou basée sur la taille, ou les deux. Il est même possible de configurer des règles qui évitent la rotation basée sur un intervalle si le fichier journal est toujours vide à l'expiration de l'intervalle. La rotation peut inclure l'envoi de fichiers journaux, la compression, la suppression, la destruction, etc.

L'utilisateur moyen n'aurait pas à se soucier trop de la rotation des journaux. Les développeurs voudront probablement s'assurer que les journaux qu'ils utilisent ont des règles de rotation établies. En fait, les développeurs ont probablement de bonnes manières de configurer la rotation des journaux au moment de l'installation pour tous les journaux spécifiques au logiciel que le logiciel va créer et écrire.


1

J'ai implémenté un simple nettoyeur ici:

https://github.com/Lin-Buo-Ren/Coward-Unix-Log-Cleaner

Il s'agit simplement:

  • Supprime les noms de fichiers avec les modèles de nom de fichier logrotated suivants sous /var/log
    • ^.*/.+\.[[:digit:]]+(\.[[:alpha:]]+)?$
    • ^.*/.+\.old$ (insensible à la casse)
  • Tronquer / vider les fichiers avec des noms de fichiers avec les modèles de nom de fichier journal suivants sous /var/log
    • ^.*/.+\.log$ (insensible à la casse)

-2
function goodbyelogs {
find /var/log -type f
}

for i in return $(goodbyelogs);
do sudo cat /dev/null > $i;
echo "Log $i has been cleared";
done

créez un script exécutable et essayez de l'exécuter en tant que root si sudo ne fonctionne pas pour vous

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.