Discussion :

[cendrine36]

Bonjour,

Je suis redhat 6.5. Depuis quelques temps j'ai ma partition système qui diminue fortement.
Les logs sont dans une partition séparé.
Nous ne retrouvons pas la capacité utilisé.
Nous avons essayé de nettoyé, mais nous ne voyons plus quoi faire.

Auriez vous une idée de piste ?
Voici actuellement la configuration des disques.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
Filesystem            1K-blocks       Used  Available Use% Mounted on
/dev/sda6                999320     800624     146268  85% /
tmpfs                   4021620          0    4021620   0% /dev/shm
/dev/sda1                999320      63336     883556   7% /boot
/dev/sda7            1889877952  791933308 1001937732  45% /data
/dev/sda11              1008632       1396     955168   1% /home
/dev/sda8               3997376     575500    3212164  16% /opt
/dev/sda10              1998672      49828    1843988   3% /tmp
/dev/sda3               3997376    1823520    1964144  49% /usr
/dev/sda9               3997376     481360    3306304  13% /usr/local
/dev/sda5               3997376    1776108    2011556  47% /var
/dev/sda12           1921813336 1288947208  535243704  71% /data2

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
0       ./.autorelabel
2,2G    ./usr
0       ./.readahead_collect
4,0K    ./media
32M     ./etc
27M     ./lib64
288M    ./lib
0       ./sys
4,0K    ./selinux
0       ./.autofsck
1,9G    ./var
756G    ./data
132K    ./home
du: impossible d'accéder Ã* «Â*./proc/9639/task/9639/fd/4Â*»: Aucun fichier ou dossier de ce type
du: impossible d'accéder Ã* «Â*./proc/9639/task/9639/fdinfo/4Â*»: Aucun fichier ou dossier de ce type
du: impossible d'accéder Ã* «Â*./proc/9639/fd/4Â*»: Aucun fichier ou dossier de ce type
du: impossible d'accéder Ã* «Â*./proc/9639/fdinfo/4Â*»: Aucun fichier ou dossier de ce type
du: impossible d'accéder Ã* «Â*./proc/9919Â*»: Aucun fichier ou dossier de ce type
du: impossible d'accéder Ã* «Â*./proc/9920Â*»: Aucun fichier ou dossier de ce type
du: impossible d'accéder Ã* «Â*./proc/9921Â*»: Aucun fichier ou dossier de ce type
du: impossible d'accéder Ã* «Â*./proc/9922Â*»: Aucun fichier ou dossier de ce type
0       ./proc
4,0K    ./cgroup
288K    ./root
15M     ./sbin
16K     ./lost+found
555M    ./opt
5,2G    ./mnt
7,8M    ./bin
4,0K    ./srv
61M     ./boot
1,3T    ./data2
268K    ./dev
4,0K    ./CdbsMutex
46M     ./tmp
2,0T    .

Merci par avance

[Escapetiger]

Bonjour,

Je suis redhat 6.5. Depuis quelques temps j'ai ma partition système qui diminue fortement.
Les logs sont dans une partition séparé.
Nous ne retrouvons pas la capacité utilisé.
Nous avons essayé de nettoyé, mais nous ne voyons plus quoi faire.

Auriez vous une idée de piste ?
Voici actuellement la configuration des disques.
(...)
Merci par avance

Bonjour,

Si j'ai bien compris ton interrogation, c'est la capacité de ta partition système (au sens l'espace libre) qui diminue fortement. Alors si c'est le cas, je te suggère, comme première piste, d'utiliser la commande find comme ci-dessous par exemple, c'est en lecture seule :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 find / -xdev -size +10000 -exec ls -al {};

qui retournera exclusivement sur la racine (l' otion xdev) tous les fichiers d'une taille supérieure à 10000 octets (~ 10 Mo, on peut évidemment changer la valeur), le "ls -al" permettant de vérifier la date de création/modification.
Voir le man find de l'OS pour la syntaxe et les options.

Il arrive que des installations "à l'arrache" ne créent pas le filesystem qui va bien et/ou le lien symbolique et l'ensemble (applicatifs, logs, etc...) se retrouve dans la racine ("/") qui, au fil du temps devient pleine.

[Edit] pas de Red Hat en ce moment ici, rajouter peut-être (de mémoire) un "anti-slash" "\" devant le point-virgule ";"

[frp31]

le compte root doit avoir un .bash_history ou un truc du genre qui gonfle tranquillement au fil de l'eau....
les mails root si tu les conserve sous forme de mbox au lieu de les purger ça peut expliquer aussi

[Siguillaume]

Bonjour, cela peut être aussi lié à kdump. Il copie l'emprunte de la mémoire sur le disque en cas d'arrêt brusque ou de crash du système.
Quand il n'est pas bien configuré il peut générer beaucoup d'occupations d'espace.

[cendrine36]

bonjour,

j'ai effectué la recherche et cela m'affiche :



Ce serveur ne fait pas serveur de mail.

J'ai regardé les fichiers .bash_history ils sont de faible taille


Au niveau de kdump je ne connais pas du tout. Pourriez vous m'aiguiller.

Merci

[Flodelarab]

Bonjour,

déjà, j'irais voir le gestionnaire de paquets, pour supprimer tout ce qui encombre (logiciel inutilisé, logiciel installé et désinstallé mais ayant laissé des fichiers temporaires, ...).

Après, une photo seule ne suffit pas. Il faut que tu prennes 2 photos. Et que tu les compares. Ainsi, tu verras ce qui grandit.

J'ai un peu de mal à comprendre pourquoi il n'y a que 3 lignes. C'est un échantillon ? Tu aurais pu copier/coller dans un balise "code" (signe # dans la barre d'outil) plutôt que t'embêter à faire une image.

[cendrine36]

Ce n'est pas un échantillon, il y a que c'est 3 fichiers qui s'affiche.
J'ai déjà épuré au maximum, je ne vois plus quoi supprimé. D'où ma demande.
Merci

[Escapetiger]

Ce n'est pas un échantillon, il y a que c'est 3 fichiers qui s'affiche.
J'ai déjà épuré au maximum, je ne vois plus quoi supprimé. D'où ma demande.
Merci

Dans ces cas là, il faut y aller comme un forçat find / -xdev ! -type d -mtime -7 -exec ls -al {} \; pour afficher la totalité des fichiers de la racine qui ne soient pas des répertoires et qui ont été modifiés et /ou créés depuis moins de 7 jours par exemple, voire enlever l'option -mtime pour la totale.

Mieux vaut poster un fichier joint; chez moi sur mon petit Linux, ça affiche plus de 24 000 lignes !

[Edit]

Après, une photo seule ne suffit pas. Il faut que tu prennes 2 photos. Et que tu les compares. Ainsi, tu verras ce qui grandit.

Tout à fait, d'ailleurs à ce propos, peux-tu nous fournir les mêmes traces qu'en début de post histoire de se faire une idée sur cette courte période ?

[Flodelarab]

Pardon mais je pense que s'obstiner avec ls n'est pas bon. Si le système n'a pas de fichier obèse, alors, il crée peut-être un myriade de petits fichiers. Dans ce cas là, c'est le contraire de ce que tu dis: find ... -type d d'une part et du d'autre part.

D'ailleurs, pour prendre une photo, je liste les dossiers les plus éloignés de la racine de plus de 10Mo et les fichiers de plus de 10Mo. Il est amusant de noter qu'aucun logiciel ne permette ce nettoyage facilement. Entre ceux qui considèrent que la taille d'un dossier est 0 (ou presque), ce qui ne permet pas de reconnaître un dossier obèse, et ceux qui considèrent que la taille d'un dossier est la somme de la taille des contenus, ce qui va lister / /home /home/polo /home/polo/Document etc... pour un gros fichier en feuille et empêcher de reconnaître un gros dossier s'il y a un gros fichier, TOUT LE MONDE a tort.

Il ne reste qu'une solution: le script perso.

[Escapetiger]

Pardon mais je pense que s'obstiner avec ls n'est pas bon. Si le système n'a pas de fichier obèse, alors, il crée peut-être un myriade de petits fichiers. Dans ce cas là, c'est le contraire de ce que tu dis: find ... -type d d'une part et du d'autre part.

D'ailleurs, pour prendre une photo, je liste les dossiers les plus éloignés de la racine de plus de 10Mo et les fichiers de plus de 10Mo. Il est amusant de noter qu'aucun logiciel ne permette ce nettoyage facilement. Entre ceux qui considèrent que la taille d'un dossier est 0 (ou presque), ce qui ne permet pas de reconnaître un dossier obèse, et ceux qui considèrent que la taille d'un dossier est la somme de la taille des contenus, ce qui va lister / /home /home/polo /home/polo/Document etc... pour un gros fichier en feuille et empêcher de reconnaître un gros dossier s'il y a un gros fichier, TOUT LE MONDE a tort.

Il ne reste qu'une solution: le script perso.

Tout à fait d'accord avec ton analyse, je pense que l'option -mtime -7 et le du permettent d'affiner la photo pourvu qu'on les lance régulièrement, qu'on stocke le résultat sous forme de fichier .txt pour comparer ensuite avec des commandes du style diff, etc ... On en revient donc, comme tu le dis, à un script perso.

La connaissance des applicatifs du serveur (sa finalité) devrait également être une piste (cf. le gestionnaire de paquets que tu as mentionné également, voir http://linux.die.net/man/8/rpm).

Après, Cendrine nous écrit ce qu'elle applique, on ne sait pas si c'est un serveur de production sensible, si elle a les droits de tout vérifier voire modifier ensuite, etc...

[jlliagre]

Nous ne retrouvons pas la capacité utilisé.

Oui, df dit que 800Mo sont utilisés dans la partition / alors que du ne trouve que 370 Mo.

Nous avons essayé de nettoyé, mais nous ne voyons plus quoi faire.
Auriez vous une idée de piste ?

Le problème peut venir de cette tentative de nettoyage si la commande rm seule a été utilisée sur des fichiers ouverts par des applications.

Il est assez facile de les identifier avec cette commande:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

lsof | grep deleted

Si des fichiers effacés par sont détectés par lsof, c'est qu'ils sont toujours ouverts.

Un rédémarrage des processus maintenant ces fichiers ouverts permet de libérer l'espace disque.

Pour effacer efficacement un fichier par la suite, on peut exécuter ces deux commandes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
: > fichier
rm fichier