Comment puis-je empêcher /var/log/kern.log.1 de consommer tout mon espace disque?

9

J'ai un disque dur de 80 Go sans partition. Un jour, j'ai réalisé que j'avais perdu la plupart de mon espace disque libre. J'ai découvert que cela /var/log/kern.log.1prend 25 Go d'espace et qu'il n'y a pas d'option de suppression pour ce fichier.

Voici une capture d'écran du problème:

20130110-125652

Je suis nouveau sur Ubuntu / Linux. Veuillez aider. Merci.

kernel syslog Abhishek Prakash
la source
Quelle est la taille des autres fichiers kern.log de ce répertoire? Est kern.log.1le seul gros fichier?
qbi
oui kern.log.1 est le seul gros fichier, d'autres sont de l'ordre de quelques Mo
Abhishek Prakash
En général, il peut être préférable de supprimer le fichier comme l'a suggéré @elias. Cependant, un journal aussi volumineux indique généralement qu'il y a ou qu'il y avait un problème. Vous devez donc surveiller si votre système produit à nouveau un fichier aussi volumineux. Si oui, vous devriez consulter le fichier.
qbi

Réponses:

7

Vous devriez bien supprimer ce fichier, car il s'agit d'un journal déjà tourné. Comme vous avez besoin d'autorisations root pour ce faire, vous n'aurez pas d'option dans l'interface graphique pour supprimer ce fichier.

Vous pouvez le faire à partir de la ligne de commande:

sudo rm /var/log/kern.log.1

Chaque fois que vous démarrez, les fichiers journaux sont créés et pivotés à nouveau, vous devez donc probablement surveiller les prochaines tailles de fichier kern.log. *. Rapport de bogue associé sur Launchpad: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/115774

elias
la source
4

syslog

  • Pour éviter à l'avenir des fichiers journaux trop volumineux, modifiez /etc/logrotate.confpour limiter le nombre et la taille des fichiers journaux. Voir man logrotatepour plus d'informations.

systemd

xiota
la source
1
Ou désactivez syslog et utilisez le journal. Les choses vont dans ce sens, ce n'est qu'une question de temps.
Metta Crawler
1

kern.log.1 n'est qu'un des nombreux fichiers journaux du noyau.

Ensemble, eux et le messages.log.xgroupe peuvent occuper de nombreux Go. Les autres fichiers journaux du répertoire occupent environ 1% du total, il n'est donc pas nécessaire d'essayer d'effacer en masse le répertoire des journaux. Cela pourrait même être dangereux pour votre système.

Pour récupérer que 99%, voici deux commandes qui feront l'affaire en supprimant les fichiers multi-Go inutiles:

sudo rm /var/log/kern* &>/dev/null
sudo rm /var/log/messages* &>/dev/null

Ces fichiers seront recréés la première fois qu'ils seront nécessaires.

Pour répondre spécifiquement à votre question: Vous pouvez configurer un travail cron pour les supprimer à minuit, ou une fois par semaine, selon le cas.

Je les utilise en plus

rm -rf ~/.cache/chromium/Default/Cache/* &>/dev/null

pour ma rsyncsauvegarde de minuit du SSD principal / dev / sda vers le plus grand disque dur / dev / sdb. Il économise de l'espace et ils ne sont pas nécessaires dans tout type de scénario de restauration.

SDsolar
la source
1
Ce n'est pas vrai que ce comportement est intégré à Linux. Le noyau Linux écrit simplement ces messages de journal dans des tampons internes (en mémoire) auxquels les applications de l'espace utilisateur peuvent accéder. C'est un démon syslog qui tire ensuite ces journaux et les écrit dans / var / log. Ce démon peut très bien être configuré ou même complètement désactivé.
Dreamer
Point bien pris. Il y a beaucoup de messages de journal qui sont nécessaires pour les développeurs avancés, donc je ne suggère pas de le fermer complètement. J'exécute une rsyncsauvegarde nocturne du SSD / dev / sda vers le grand disque dur / dev / sdb, et afin de faire le meilleur usage de l'espace, je le fais faire ci-dessus, plus aussi rm -rf /home/pi/.cache/chromium/Default/Cache/* &>/dev/nullcar aucun d'entre eux n'est nécessaire dans le scénario de restauration .
SDsolar
1
J'exécute généralement ces deux commandes suivantes avant de redémarrer: find /var/log/ -type f \( -name "*.gz" -o -name "*.1" -o -name "*.old" \) -deleteet find /var/log/ -type f -exec truncate -s 0 {} \;cela nettoie l'ensemble / var / log sans supprimer les fichiers principaux, car certains fichiers ne sont pas générés automatiquement à nouveau.
Videonauth
1

Après avoir constaté que les fichiers syslog et kern.log augmentaient, j'ai manqué d'espace disque. Le gestionnaire d'espace disque m'a montré que le /var/logdossier prenait beaucoup d'espace. Quand j'ai exécuté la commande

tail -15 syslog

J'ai trouvé des erreurs répétitives. Les fichiers syslog et kern.log ont également pris respectivement 19 et 32 ​​G. (commande pour l'utilisation du disque: du -h filename-h pour la lisibilité humaine).

La suppression de ces fichiers est sûre, pour ceux qui seront recréés par le système. Mais si vous avez besoin d'un enregistrement du journal des semaines avant, ne le faites pas, car ceux-ci ne sont pas dupliqués.

Remarque (seule suggestion):

1) Si vous n'êtes pas au courant du système de fichiers Linux, c'est le bon lien: https://help.ubuntu.com/community/LinuxFilesystemTreeOverview

2) Plus d'informations sur les fichiers journaux: https://help.ubuntu.com/community/LinuxLogFiles

Parcourir ces liens effacera de nombreux concepts.

Delsilon
la source
Merci, beaucoup d'informations utiles pour un débutant Linux comme moi. L'info est là ... trouver que c'est le problème!
B.Tanner
Le trouver est également un problème. Si vous consultez la documentation du système de fichiers Linux de Google, elle n'affiche pas non plus la documentation ci-dessus. Il n'est visible que lorsque vous tapez la documentation de présentation de l'arborescence du système de fichiers linux. Trouver le bon mot-clé pour googler est très difficile pour moi. Fait intéressant, je suis aussi un débutant;)
Delsilon
Beaucoup, beaucoup d'autres articles intéressants dans le répertoire parent du lien ci-dessus, c'est-à-dire. help.ubuntu.com/community Voilà mon temps libre pour les prochains jours!
B.Tanner
Vraiment mec, je n'ai pas examiné cette chose. J'ai l'impression d'avoir trouvé des trucs dorés. Merci de m'avoir montré cette chose. Actuellement, je travaille sur un projet totalement différent mais les trucs Linux mangent tout mon temps.
Delsilon