Bonjour,
Je suis sous une redhat avec un noyau 2.4.9
Mon probleme : j'ai eu un /var à 100 % , visible avec un "df" j'ai vidé le
/var/spool/mqueue responsable (vu avec un "du" dans /var). Cependant, le df
ne semble pas au courant du nettoyage car malgré le fait qu'il y ait environ
60 % d'espace libre confirmé par "du", la commande "df" elle, m'affiche
toujours 100 %.
Bizarrement (mais quelqu'un saura certainement me l'expliquer) cette erreur
de rafraichissement m'empeche, depuis un pc Windows de faire les montages
samba habituels que cette machine partage.
Le seul moyen que j'ai trouvé pour redonner à "df" un affichage cohérent,
c'est en redémarrant la machine Linux, solution un peu lourde.
Quelqu'un voit-il d'où vient le problème?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
TiChou
Dans le message <news:d8c0bh$20d$, *Billy BOY* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
Je suis sous une redhat avec un noyau 2.4.9 Mon probleme : j'ai eu un /var à 100 % , visible avec un "df" j'ai vidé le /var/spool/mqueue responsable (vu avec un "du" dans /var). Cependant, le df ne semble pas au courant du nettoyage car malgré le fait qu'il y ait environ 60 % d'espace libre confirmé par "du", la commande "df" elle, m'affiche toujours 100 %. Bizarrement (mais quelqu'un saura certainement me l'expliquer) cette erreur de rafraichissement m'empeche, depuis un pc Windows de faire les montages samba habituels que cette machine partage. Le seul moyen que j'ai trouvé pour redonner à "df" un affichage cohérent, c'est en redémarrant la machine Linux, solution un peu lourde. Quelqu'un voit-il d'où vient le problème?
Problème classique qui s'explique par le fait que les fichiers volumineux qui ont été supprimés étaient en cours d'utilisation ou plus précisément ouverts et que donc tant que ces fichiers sont ouverts, le système de fichiers les conserve. La bonne méthode aurait été d'arrêter les processus en cours (par exemple en passant en mode single user), de faire le nettoyage et de relancer les processus.
Merci par avance.
De rien.
-- TiChou
Dans le message <news:d8c0bh$20d$1@news.ensta.fr>,
*Billy BOY* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
Je suis sous une redhat avec un noyau 2.4.9
Mon probleme : j'ai eu un /var à 100 % , visible avec un "df" j'ai vidé le
/var/spool/mqueue responsable (vu avec un "du" dans /var). Cependant, le
df ne semble pas au courant du nettoyage car malgré le fait qu'il y ait
environ 60 % d'espace libre confirmé par "du", la commande "df" elle,
m'affiche toujours 100 %.
Bizarrement (mais quelqu'un saura certainement me l'expliquer) cette
erreur de rafraichissement m'empeche, depuis un pc Windows de faire les
montages samba habituels que cette machine partage.
Le seul moyen que j'ai trouvé pour redonner à "df" un affichage cohérent,
c'est en redémarrant la machine Linux, solution un peu lourde.
Quelqu'un voit-il d'où vient le problème?
Problème classique qui s'explique par le fait que les fichiers volumineux
qui ont été supprimés étaient en cours d'utilisation ou plus précisément
ouverts et que donc tant que ces fichiers sont ouverts, le système de
fichiers les conserve.
La bonne méthode aurait été d'arrêter les processus en cours (par exemple en
passant en mode single user), de faire le nettoyage et de relancer les
processus.
Dans le message <news:d8c0bh$20d$, *Billy BOY* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
Je suis sous une redhat avec un noyau 2.4.9 Mon probleme : j'ai eu un /var à 100 % , visible avec un "df" j'ai vidé le /var/spool/mqueue responsable (vu avec un "du" dans /var). Cependant, le df ne semble pas au courant du nettoyage car malgré le fait qu'il y ait environ 60 % d'espace libre confirmé par "du", la commande "df" elle, m'affiche toujours 100 %. Bizarrement (mais quelqu'un saura certainement me l'expliquer) cette erreur de rafraichissement m'empeche, depuis un pc Windows de faire les montages samba habituels que cette machine partage. Le seul moyen que j'ai trouvé pour redonner à "df" un affichage cohérent, c'est en redémarrant la machine Linux, solution un peu lourde. Quelqu'un voit-il d'où vient le problème?
Problème classique qui s'explique par le fait que les fichiers volumineux qui ont été supprimés étaient en cours d'utilisation ou plus précisément ouverts et que donc tant que ces fichiers sont ouverts, le système de fichiers les conserve. La bonne méthode aurait été d'arrêter les processus en cours (par exemple en passant en mode single user), de faire le nettoyage et de relancer les processus.
Merci par avance.
De rien.
-- TiChou
TiChou
Dans le message <news:, *TiChou* tapota sur f.c.o.l.configuration :
Problème classique qui s'explique par le fait que les fichiers volumineux qui ont été supprimés étaient en cours d'utilisation ou plus précisément ouverts et que donc tant que ces fichiers sont ouverts, le système de fichiers les conserve. La bonne méthode aurait été d'arrêter les processus en cours (par exemple en passant en mode single user), de faire le nettoyage et de relancer les processus.
Précisons que l'outil lsof peut dans ce cas se montrer bien utile pour trouver les fichiers effacés à l'état ouvert et les processus qui les ont ouvert.
$ lsof | grep -w DEL
-- TiChou
Dans le message <news:pwet.20050610162254@florizarre.tichou.org>,
*TiChou* tapota sur f.c.o.l.configuration :
Problème classique qui s'explique par le fait que les fichiers volumineux
qui ont été supprimés étaient en cours d'utilisation ou plus précisément
ouverts et que donc tant que ces fichiers sont ouverts, le système de
fichiers les conserve.
La bonne méthode aurait été d'arrêter les processus en cours (par exemple
en passant en mode single user), de faire le nettoyage et de relancer les
processus.
Précisons que l'outil lsof peut dans ce cas se montrer bien utile pour
trouver les fichiers effacés à l'état ouvert et les processus qui les ont
ouvert.
Dans le message <news:, *TiChou* tapota sur f.c.o.l.configuration :
Problème classique qui s'explique par le fait que les fichiers volumineux qui ont été supprimés étaient en cours d'utilisation ou plus précisément ouverts et que donc tant que ces fichiers sont ouverts, le système de fichiers les conserve. La bonne méthode aurait été d'arrêter les processus en cours (par exemple en passant en mode single user), de faire le nettoyage et de relancer les processus.
Précisons que l'outil lsof peut dans ce cas se montrer bien utile pour trouver les fichiers effacés à l'état ouvert et les processus qui les ont ouvert.
$ lsof | grep -w DEL
-- TiChou
lolotux
Billy BOY wrote:
Bonjour, Je suis sous une redhat avec un noyau 2.4.9 Mon probleme : j'ai eu un /var à 100 % , visible avec un "df" j'ai vidé le /var/spool/mqueue responsable (vu avec un "du" dans /var). Cependant, le df ne semble pas au courant du nettoyage car malgré le fait qu'il y ait environ 60 % d'espace libre confirmé par "du", la commande "df" elle, m'affiche toujours 100 %. Bizarrement (mais quelqu'un saura certainement me l'expliquer) cette erreur de rafraichissement m'empeche, depuis un pc Windows de faire les montages samba habituels que cette machine partage. Le seul moyen que j'ai trouvé pour redonner à "df" un affichage cohérent, c'est en redémarrant la machine Linux, solution un peu lourde. Quelqu'un voit-il d'où vient le problème?
Merci par avance.
============= > Billy BOY ============= Salut,
personnellement j'ai le même problème ! Mais il a été résolue grace à un script effacant les /var/log/message...etc Puis d'un /etc/init.d/syslog restart !
Le syslog est important ! pour passer de 100% à X%
Billy BOY wrote:
Bonjour,
Je suis sous une redhat avec un noyau 2.4.9
Mon probleme : j'ai eu un /var à 100 % , visible avec un "df" j'ai vidé le
/var/spool/mqueue responsable (vu avec un "du" dans /var). Cependant, le df
ne semble pas au courant du nettoyage car malgré le fait qu'il y ait environ
60 % d'espace libre confirmé par "du", la commande "df" elle, m'affiche
toujours 100 %.
Bizarrement (mais quelqu'un saura certainement me l'expliquer) cette erreur
de rafraichissement m'empeche, depuis un pc Windows de faire les montages
samba habituels que cette machine partage.
Le seul moyen que j'ai trouvé pour redonner à "df" un affichage cohérent,
c'est en redémarrant la machine Linux, solution un peu lourde.
Quelqu'un voit-il d'où vient le problème?
Merci par avance.
============= > Billy BOY
=============
Salut,
personnellement j'ai le même problème !
Mais il a été résolue grace à un script effacant les /var/log/message...etc
Puis d'un /etc/init.d/syslog restart !
Le syslog est important ! pour passer de 100% à X%
Bonjour, Je suis sous une redhat avec un noyau 2.4.9 Mon probleme : j'ai eu un /var à 100 % , visible avec un "df" j'ai vidé le /var/spool/mqueue responsable (vu avec un "du" dans /var). Cependant, le df ne semble pas au courant du nettoyage car malgré le fait qu'il y ait environ 60 % d'espace libre confirmé par "du", la commande "df" elle, m'affiche toujours 100 %. Bizarrement (mais quelqu'un saura certainement me l'expliquer) cette erreur de rafraichissement m'empeche, depuis un pc Windows de faire les montages samba habituels que cette machine partage. Le seul moyen que j'ai trouvé pour redonner à "df" un affichage cohérent, c'est en redémarrant la machine Linux, solution un peu lourde. Quelqu'un voit-il d'où vient le problème?
Merci par avance.
============= > Billy BOY ============= Salut,
personnellement j'ai le même problème ! Mais il a été résolue grace à un script effacant les /var/log/message...etc Puis d'un /etc/init.d/syslog restart !
Le syslog est important ! pour passer de 100% à X%
Rakotomandimby (R12y) Mihamina
lolotux :
personnellement j'ai le même problème ! Mais il a été résolue grace à un script effacant les /var/log/message...
logrotate a été concu dans le but de faire ce que tu à mis en oeuvre avec ton script, mais plus subtilement:
il compresse d'abord les logs, et il efface les très vieux logs.
-- Miroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
lolotux <lolo@system-linux.net> :
personnellement j'ai le même problème ! Mais il a été résolue grace
à un script effacant les /var/log/message...
logrotate a été concu dans le but de faire ce que tu à mis en oeuvre
avec ton script, mais plus subtilement:
il compresse d'abord les logs, et il efface les très vieux logs.
--
Miroir de logiciels libres http://www.etud-orleans.fr
Développement de logiciels libres http://aspo.rktmb.org/activites/developpement
Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
personnellement j'ai le même problème ! Mais il a été résolue grace à un script effacant les /var/log/message...
logrotate a été concu dans le but de faire ce que tu à mis en oeuvre avec ton script, mais plus subtilement:
il compresse d'abord les logs, et il efface les très vieux logs.
-- Miroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
