OVH Cloud OVH Cloud

situation troublante après partition utilisée à 100%

3 réponses
Avatar
Mikael
Bonjour,

Ma partition /var s'est vu remplie à 100% à cause d'un fichier de log
(il faisait quand même 4.7 Go ! ).

J'en ai copié une partie dans une autre partition puis je l'ai effacé.
Résultat :

# df -h /var
Système de fichiers Tail. Util.Disp. Uti% Monté sur
/dev/sda2 4.8G 105M 4.4G 3% /var

# cd /var/
# du -h | tail -1
73M .

Vous y comprenez quelque chose ?

Mikael

3 réponses

Avatar
Mikael
Mikael wrote:

Bonjour,

Ma partition /var s'est vu remplie à 100% à cause d'un fichier de log
(il faisait quand même 4.7 Go ! ).

J'en ai copié une partie dans une autre partition puis je l'ai effacé.
Résultat :

# df -h /var
Système de fichiers Tail. Util.Disp. Uti% Monté sur
/dev/sda2 4.8G 105M 4.4G 3% /var

# cd /var/
# du -h | tail -1
73M .

Euh, j'ai rien dit :)

J'ai été induit en erreur car j'ai tenté de copier le fichier tronqué
sur /var/log après l'effacement de l'original et ça a échoué car /var
plein à 100%.
Il fallait probablement attendre un "sync" de l'os

Mikael

Avatar
Licence IV
Le Fri, 25 Jun 2004 13:47:04 +0200, après mûre réflexion,
Mikael a écrit:
# cd /var/
# du -h | tail -1
73M .


Essayes:
du -sh
Et tu m'en dira des nouvelles!
sinon autre option sympatique: --max-depth=1

--
Nicolas de Ferrières Mail:
_______________________________________________________________
Si l'alcool ne me tue pas... Les femmes auront ma peau

Avatar
Michel Tatoute

Bonjour,

Ma partition /var s'est vu remplie à 100% à cause d'un fichier de log
(il faisait quand même 4.7 Go ! ).

J'en ai copié une partie dans une autre partition puis je l'ai effacé.
Résultat :

# df -h /var
Système de fichiers Tail. Util.Disp. Uti% Monté sur
/dev/sda2 4.8G 105M 4.4G 3% /var

# cd /var/
# du -h | tail -1
73M .

Vous y comprenez quelque chose ?

Mikael


Outre ton pb de copie, en fait effacer un fichier ouvert (or un fichier de
log est generalement ouvert en permanence) ne libere pas la place de ce
fichier.

En effet un fichier ouvert va bien disparaitre du repertoire, mais
contunera a etre present pour le process qui le tient. (un peu comme avec
la commande ln )

Pour les fichiers de log il existe logrotate. En cas d'urgence (fichier de
log geant a liberer de suite , par exemple decouverte d'un deni de
service), il faut VIDER le fichier. Attention, ce n'est pas une procedure
normale

# ls -ls /var/log/syslog
6000125 -rw------- 1 root adm 6000125771 3 jun 25 16:22 /var/log/syslog
# df
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/ide/host0/bus0/target0/lun0/part8
10G 10G 1M 99% /
# >/var/log/syslog
# ls -ls /var/log/syslog
0 -rw------- 1 root adm 0 3 jun 25 16:22 /var/log/syslog
# df
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/ide/host0/bus0/target0/lun0/part8
10G 4G 6M 40% /

# ls -ls /var/log/syslog
5 -rw------- 1 root adm 6000127584 3 jun 25 16:22 /var/log/syslog
# df
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/ide/host0/bus0/target0/lun0/part8
10G 4G 6M 40% /

Il est normal que le fichier remonte rapidement a 6Go, mais il ne prendra
plus 6G sur le disque. (fichier à trous)

Nota: mes copies d'ecran sont retraivaillées,ce qui explique les
decomptes de blocs "approximatifs".

Une fois le fichier vidé , il serait bon d'utiliser logrotate, ou de
passer en init 1 pour "nettoyer".

Michel.