Problème espace partition /var

Le
Yan
Bonjour,

Je débute dans l'administration de serveur freebsd et j'ai un soucis
dont je ne comprends pas la cause.
Je fait un df et je vois que ma partition /var est utilisé à 87% (7,8
Go).

Filesystem Size Used Avail Capacity Mounted on
/dev/da0s1a 9.7G 156M 8.8G 2% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/da0s1h 81G 17G 58G 23% /data
/dev/da0s1f 9.7G 2.5G 6.4G 28% /home
/dev/da0s1g 9.7G 242K 8.9G 0% /tmp
/dev/da0s1d 9.7G 1.2G 7.7G 14% /usr
/dev/da0s1e 9.7G 7.8G 1.2G 87% /var


Et quand je veux trouver ce qui occupe de la place, je fais un du de
la partition var: du /var
Et là ce la m'affiche 355Mo.

Donc je n'arrive pas à trouver les fichiers/répertoires qui occupent
de la place.

Merci de votre aide.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
espie
Le #21141161
In article Yan
Je débute dans l'administration de serveur freebsd et j'ai un soucis
dont je ne comprends pas la cause.
Je fait un df et je vois que ma partition /var est utilisé à 87% (7,8
Go).


Tu debutes dans l'admin unix, en fait. c'est un enorme classique.

/dev/da0s1e 9.7G 7.8G 1.2G 87% /var


Et quand je veux trouver ce qui occupe de la place, je fais un du de
la partition var: du /var
Et là ce la m'affiche 355Mo.

Donc je n'arrive pas à trouver les fichiers/répertoires qui occupent
de la place.



Lorsque tu ouvres un fichier a partir d'un process, ca te donne un file
descriptor qui te permet d'acceder au fichier. Le systeme ne regarde plus
du tout du tout quoi que ce soit cote nom de fichier ensuite.

Tu peux tres bien avoir sur ton disque des fichiers:
- qui sont ouverts par un processus (par exemple, le fichier de log d'un
daemon quelconque, assez souvent apache), et qui donc existent et prennent
de la place, comme visible dans df.
- qui n'ont plus de nom dans le filesystem, et qui donc apparaitront dans du.

C'est ce qui se passe si, par exemple, tu vois un fichier qui bouffe des mega
que tu supprimes avec rm, sans te preoccuper de savoir ce qui genere le
fichier en question.

Si c'est pas une erreur manuelle, ca sera par exemple un bug dans tes
crontab de deplacement de fichiers de log, qui a oublie de prevenir les
daemons correspondants.

Traditionnellement, les programmes serveurs sont concus par rapport a cette
fonctionnalite. Le signal HUP, qui d'habitude sert a dire qu'un programme
n'a plus de terminal de controle, est pre-empte pour les daemons (qui n'ont
plus de terminaux de controle): un daemon bien ecrit va reagir a HUP en:
- relisant ses fichiers de config,
- reouvrant tous ses fichiers de log.

Meme si on peut douter du fait qu'apache soit bien ecrit, il reagit
correctement a HUP.

Donc, regarde ce que tu as qui traine comme daemons, apache en tete,
balance-leur un HUP, attend quelques secondes et tu vas sans doute recuperer
ta place.

Si tu ne t'en sors pas comme ca, il existe des programmes (variant d'un unix
a l'autre) qui peuvent te donner la liste des fichiers ouverts et des
processus qui les tiennent. lsof, par exemple.

Pour reellement corriger ton souci, il faudra sans doute que tu determines si
la place manquante provient d'une intervention manuelle, ou si c'est une
crontab qui deconne.

C'est vraiment le BA-BA de l'admin. Je suppose que tu es auto-didacte dans
l'admin Unix. Si tu as suivi une formation d'admin et qu'on ne t'a pas appris
ca, celle-ci ne vaut rien. Si tu as lu un bouquin ou un site web, remplace-les
par des choses un peu mieux foutues...
kevin vanier
Le #21143071
Marc Espie a écrit :


C'est vraiment le BA-BA de l'admin. Je suppose que tu es auto-didacte dans
l'admin Unix. Si tu as suivi une formation d'admin et qu'on ne t'a pas appris
ca, celle-ci ne vaut rien. Si tu as lu un bouquin ou un site web, remplace-les
par des choses un peu mieux foutues...



comme ceci .
http://minilien.com/?7sjFlxuHxF
yan
Le #21148371
On 6 fév, 10:48, (Marc Espie) wrote:
In article >Je débute dans l'administration de serveur freebsd et j'ai un soucis
>dont je ne comprends pas la cause.
>Je fait un df et je vois que ma partition /var est utilisé à 87% (7, 8
>Go).

Tu debutes dans l'admin unix, en fait. c'est un enorme classique.

>/dev/da0s1e    9.7G    7.8G    1.2G    87%    /var

>Et quand je veux trouver ce qui occupe de la place, je fais un du de
>la partition var: du /var
>Et là ce la m'affiche 355Mo.

>Donc je n'arrive pas à trouver les fichiers/répertoires qui occupent
>de la place.

Lorsque tu ouvres un fichier a partir d'un process, ca te donne un file
descriptor qui te permet d'acceder au fichier.  Le systeme ne regarde p lus
du tout du tout quoi que ce soit cote nom de fichier ensuite.

Tu peux tres bien avoir sur ton disque des fichiers:
- qui sont ouverts par un processus (par exemple, le fichier de log d'un
daemon quelconque, assez souvent apache), et qui donc existent et prennen t
de la place, comme visible dans df.
- qui n'ont plus de nom dans le filesystem, et qui donc apparaitront dans du.

C'est ce qui se passe si, par exemple, tu vois un fichier qui bouffe des mega
que tu supprimes avec rm, sans te preoccuper de savoir ce qui genere le
fichier en question.

Si c'est pas une erreur manuelle, ca sera par exemple un bug dans tes
crontab de deplacement de fichiers de log, qui a oublie de prevenir les
daemons correspondants.

Traditionnellement, les programmes serveurs sont concus par rapport a cet te
fonctionnalite. Le signal HUP, qui d'habitude sert a dire qu'un programme
n'a plus de terminal de controle, est pre-empte pour les daemons (qui n'o nt
plus de terminaux de controle): un daemon bien ecrit va reagir a HUP en:
- relisant ses fichiers de config,
- reouvrant tous ses fichiers de log.

Meme si on peut douter du fait qu'apache soit bien ecrit, il reagit
correctement a HUP.

Donc, regarde ce que tu as qui traine comme daemons, apache en tete,
balance-leur un HUP, attend quelques secondes et tu vas sans doute recupe rer
ta place.

Si tu ne t'en sors pas comme ca, il existe des programmes (variant d'un u nix
a l'autre) qui peuvent te donner la liste des fichiers ouverts et des
processus qui les tiennent. lsof, par exemple.

Pour reellement corriger ton souci, il faudra sans doute que tu determine s si
la place manquante provient d'une intervention manuelle, ou si c'est une
crontab qui deconne.

C'est vraiment le BA-BA de l'admin. Je suppose que tu es auto-didacte dan s
l'admin Unix. Si tu as suivi une formation d'admin et qu'on ne t'a pas ap pris
ca, celle-ci ne vaut rien. Si tu as lu un bouquin ou un site web, remplac e-les
par des choses un peu mieux foutues...



Merci pour vos réponses.

Si je comprends bien je dois faire: "kill -HUP httpd" ?

Mais j'ai beaucoup de process httpd dans ma liste.
Je dois le faire sur tous ?

Ciao.
espie
Le #21148491
In article yan
Merci pour vos réponses.

Si je comprends bien je dois faire: "kill -HUP httpd" ?

Mais j'ai beaucoup de process httpd dans ma liste.
Je dois le faire sur tous ?



Non, sur l'ancetre des autres, qui a de bonnes chances d'appartenir a root...

(note: si ma reponse etait un peu longue, c'est parce que tu ne t'en
sortiras pas avec une "recette". Il faut vraiment que tu comprennes ce
qui se passe. Il est *vraisemblable* que c'est apache qui tient tes
fichiers en otage, mais ca peut etre un autre daemon).
yan
Le #21150211
On 7 fév, 17:25, (Marc Espie) wrote:
In article
yan   >Merci pour vos réponses.

>Si je comprends bien je dois faire: "kill -HUP httpd" ?

>Mais j'ai beaucoup de process httpd dans ma liste.
>Je dois le faire sur tous ?

Non, sur l'ancetre des autres, qui a de bonnes chances d'appartenir a roo t...

(note: si ma reponse etait un peu longue, c'est parce que tu ne t'en
sortiras pas avec une "recette". Il faut vraiment que tu comprennes ce
qui se passe. Il est *vraisemblable* que c'est apache qui tient tes
fichiers en otage, mais ca peut etre un autre daemon).



Oui oui, je comprends très bien.

J'ai essayé de killer apache mais rien ne changeait.

Comme ca commençait à urger, j'ai redémarré le serveur et là j'ai
récupéré tout mon espace.

Merci pour votre aide.
xavier
Le #21150371
yan
Si je comprends bien je dois faire: "kill -HUP httpd" ?



Hum... Il y a dans FreeBSD des mécanismes pour faire ça proprement :

sudo /usr/local/etc/rc.d/apache stop

--
XAv
Disponible au 01/06/2010
Vivien MOREAU
Le #21150481
On 2010-02-07, Xavier wrote:

yan
Si je comprends bien je dois faire: "kill -HUP httpd" ?



Hum... Il y a dans FreeBSD des mécanismes pour faire ça proprement :

sudo /usr/local/etc/rc.d/apache stop



C'est pas kill httpd, c'est kill -HUP httpd.

--
Vivien MOREAU / vpm

« Unix is simple. It just takes a genius to understand its simplicity »
Dennis M. Ritchie
xavier
Le #21150551
Vivien MOREAU
C'est pas kill httpd, c'est kill -HUP httpd.



Alors dans ce cas, un "apachectl reload" fera l'affaire

--
XAv
Disponible au 01/06/2010
espie
Le #21150631
In article Xavier
Vivien MOREAU
C'est pas kill httpd, c'est kill -HUP httpd.



Alors dans ce cas, un "apachectl reload" fera l'affaire



ce qui au final, fait la meme chose.
C'est bien qu'apache & co aient invente des trucs a eux plus ou moins
standard pour ce genre de chose, mais le coup du -HUP sur les daemons,
ca predate le apachectl reload de quelques annees, et ca le bon gout
de marcher tres souvent meme lorsque tu n'as pas de foo reload (voire
meme sur certains os ou la qualite des scripts de lancement/arret de
daemons laisse franchement a desirer...)
xavier
Le #21151661
Marc Espie
ce qui au final, fait la meme chose.



On est d'accord

C'est bien qu'apache & co aient invente des trucs a eux plus ou moins
standard pour ce genre de chose, mais le coup du -HUP sur les daemons,



Dans ce cas, j'airaus tendance à préférer, sur les OS où ça existe
`killall -HUP httpd`

ca predate le apachectl reload de quelques annees, et ca le bon gout
de marcher tres souvent meme lorsque tu n'as pas de foo reload (voire
meme sur certains os ou la qualite des scripts de lancement/arret de
daemons laisse franchement a desirer...)



Des noms ? :-)


--
Xav
Disponible au 01/04/2010
Publicité
Poster une réponse
Anonyme