Vous avez des journaux hors de contrôle. Au lieu de supprimer comme des fous tous les jours, trouvez le ou les fichiers à croissance rapide et regardez à l' intérieur pour rechercher la cause de ce problème. Peut-être qu'un programme tourne dans une boucle enregistrant une condition. Désactivez ce programme, désactivez sa journalisation ou essayez de corriger la condition dont il se plaint.
Si un fichier se développe sous vos yeux et que vous ne savez pas quel programme y écrit, vous pourrez peut-être le découvrir facilement. Voici un exemple. Qui a /var/log/syslogouvert? Nous utilisons la fusercommande:
# fuser /var/log/syslog
/var/log/syslog: 602
Un seul processus s'est /var/log/syslogouvert. C'est le processus 602. Qu'est-ce que c'est? Ne nous occupons pas de pset grep, mais regardons /procdirectement le système de fichiers:
# ls -l /proc/602/exe
lrwxrwxrwx 1 root root 0 Mar 29 17:45 /proc/602/exe -> /usr/sbin/rsyslogd
Aha, ça l'est rsyslogd. Nous ne sommes pas surpris que cela se rsyslogdsoit /var/log/syslog/ouvert.
Cette méthode n'est pas garantie de fonctionner. La raison en est que les programmes n'ont pas besoin de garder les fichiers ouverts pour pouvoir y écrire. Supposons que vous ayez un processus qui ouvre un fichier, y ajoute, puis le ferme. Vous aurez une enquête un peu plus difficile. Vous pouvez exécuter fuserplusieurs fois jusqu'à ce que vous preniez par hasard le processus "en flagrant délit". Ce processus lui-même pourrait entrer et disparaître rapidement. Un autre problème est que plusieurs processus peuvent ouvrir le fichier, mais un seul le rend plus grand. Dans ce cas, vous pouvez suivre leurs appels système.
# fuser /var/log/huge-annoying-file
/var/log/huge-annoying-file: 1234 23459
Oups! Deux processus l'ont ouvert: 1234 et 23459. Voyons ce qu'ils font:
# strace -p 1234
Process 1234 attached - interrupt to quit
select(1, NULL, NULL, NULL, {9, 922666}
Il ne fait rien, il bloque simplement un selectappel. Ctrl-C pour casser la trace:
select(1, NULL, NULL, NULL, {9, 922666}^C <unfinished ...>
Vérifiez le suivant:
# strace -p 23459
write(5, "Useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
^C
Oups, celui-là écrit constamment. Ce doit être le mauvais. On peut même vérifier que le descripteur de fichier 5 sur lequel le processus écrit est bien le gros fichier:
# ls -l /proc/23459/fd/5
lr-x------ 1 root root 64 Apr 3 23:39 /proc/23459/fd/5 -> /var/log/huge-annoying-file
Je ne pense pas que vous ayez un système de fichiers corrompu, mais pour forcer une vérification complète, vous n'avez pas besoin de démarrer un DVD.
Tout d'abord, passez en revue le paramètre de nombre maximal de montages de votre système de fichiers. Identifiez votre partition à l'aide de la commande df. Exemple sur un système Ubuntu que j'ai ici:
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 18062108 5499320 11645284 33% /
udev 392152 4 392148 1% /dev
tmpfs 159768 768 159000 1% /run
none 5120 0 5120 0% /run/lock
none 399416 200 399216 1% /run/shm
/dev/sr0 43668 43668 0 100% /media/VBOXADDITIONS_4.1.4_74291
Vous pouvez voir que le /système de fichiers est monté sur /dev/sda1. Il en /dev/sda1va de même du périphérique de stockage de la partition racine (et de la seule partition de ce système particulier).
Examinons quelques attributs de ce système de fichiers. C'est sûr à faire même s'il est monté. La commande crache beaucoup de sortie. En voici un extrait:
$ dumpe2fs /dev/sda1
dumpe2fs 1.42 (29-Nov-2011)
Filesystem volume name: <none>
Last mounted on: /
[ ... SNIP ... ]
Last mount time: Fri Mar 29 17:45:18 2013
Last write time: Tue Mar 5 09:08:03 2013
Mount count: 22
Maximum mount count: 22
[ ... SNIP ... ]
Hé, regardez, le nombre de montages est égal au nombre de montages maximum. La prochaine fois que je redémarrerai, il y aura une vérification du système de fichiers. L'important est que le nombre de montages soit une valeur positive. Si le vôtre est nul, changez-le en une valeur positive comme 22 en utilisant tune2fs -c 22 /dev/whatever. Zéro signifie qu'une vérification n'est jamais forcée quel que soit le nombre de fois où la partition est montée. Les systèmes rarement redémarrés devraient avoir des valeurs faibles ici. Un serveur qui tombe en panne une fois par an pourrait probablement utiliser un fsck à chaque redémarrage. Vous pouvez également définir des intervalles de vérification basés sur la date.
Maintenant, pour forcer une vérification, vous pouvez remplacer le nombre réel pour être supérieur ou égal au maximum, puis redémarrer. Cela se fait avec le capital C: tune2fs -C 1234 /dev/whatever. Maintenant, la partition semble avoir été montée 1234 fois sans vérification, ce qui est supérieur au maximum à un ou deux chiffres.
sudo du -sh /var/* ~/.xsession-errorss'il vous plaît? (Ces deux endroits, je m'attends à ce qu'ils explosent s'il y a quelque chose de stupide). Sinon, je suis avec Eliah - cela indique des problèmes de disque. Prenez cela au sérieux.