Re: Impossible de démarrer en GUI , partition /dev/sdax utilisé à 100%

Le
Belaïd MOUNSI
--089e013d1db2de4d6704e69117fa
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Bonjour,
lsof permet de voir les fichiers qui sont en cours d'utilisations par les
process. Par:* lsof | grep -i nom_de_ton_gros_fichier* je voulais être su=
r
que ton gros fichier n'est pas encore en cours d'utilisation (même suppri=

un fichier peut encore être présent sur le disque, et aussi sur mémoi=
re
s'il est encore en cours d'utilisation).


Le 17 septembre 2013 11:32, Dorian Carpentier de Changy <
dechangydorian@yahoo.fr> a écrit :

> df -ih
> Sys.de fichiers Inodes IUtilisé ILib.
> IUti% Monté sur
> /dev/sda5 598K 163K 436K 28% /
> tmpfs 354K 5 354K
> 1% /lib/init/rw
> udev 336K 892 335K
> 1% /dev
> tmpfs 354K 2 354K
> 1% /dev/shm
> overflow 354K 1 354K
> 1% /tmp
>
> L'utilisation des Inodes montre que 72% sont inoccupés !?
>
>
> Sys.de fichiers 1K-blocs Utilisé Dispo.
> Uti% Monté sur
> /dev/sda5 9620408 9620408 0 100%
> /
> tmpfs 1449340 0 1449340
> 0% /lib/init/rw
> udev 1373708 272 1373436
> 1% /dev
> tmpfs 1449340 0 1449340
> 0% /dev/shm
> overflow 1024 0 1024
> 0% /tmp
>
>
>
>
> Le 16/09/2013 13:15, Johnny B a écrit :
>
> Salut,
>
> A tous les coups tu as tes inodes full
>
> Fais un df -ih
>
> Le 09/16/2013 12:40 PM, Belaïd MOUNSI a écrit :
>
> Bonjour,
> Que donne la commande suivante:
> lsof | grep -i le_nom_de_ton_fichier
>
>
> Le 16 septembre 2013 11:57, Dorian <dechangydorian@yahoo.fr> a écrit :
>
>> Bonjour,
>>
>> Suite à l'encodage d'un vidéo sous PiTiVi, j'ai obtenu un fichier qu=
i a
>> occupé tt l'espace disque restant(3.9G sur un volume de 9G).
>> J'ai souhaité supprimer le fichier. puis Reboot. Lors de la fermeture,=
le
>> système freezais avant d'envoyer le TERM.
>> J'ai forcé la fermeture par le bouton power du portable.
>> JE redémarre et constate que j'ai accès que à la CLI.
>> df signale, 100% sur /dev/sda5 (le volume logique sur lequel est install=
é
>> Squeeze avec noyau Xen-4.0, plusieurs LV créés mais inutilisés, il=
y a des
>> messages d'erreurs leur cc au démarrage, à tt hazard)
>> J'ai retrouvé le fichier qui à ma connaissance (je n'ai pas vérifi=
er à
>> l'ai de de ls -hla <nom fichier>) et l'ai supprimé rm.
>> Le fichier n'existe bien plus. df m'indique tjs 100% d'utilisation sur
>> /dev/sda5. Mais je ne sais pas comment/quel répertoire/fichier occupe =
tt
>> cet espace.
>> free m'indique que le swap est vide. ram utilisé à 10 %
>>
>>
>> Le texte qui s'affiche au lancement de la machine m'affiche:
>> starting Avahi mDNS/DNS-SD Daemon : avahi-daemon Failed!
>> uname: write error : No space left on device
>> cat: write error : No space left on device
>>
>> Can't start hardware abstraction layer - please ensure dbus is running
>> failed!
>>
>> Un init 5 ou init 3 ne me permet pas rentrer ds la GUI.
>>
>> JE dois pouvoir retrouver le contrôle sur la GUI, je mène un teste s=
ur
>> XEN.
>>
>> MErci de votre support,
>>
>>
>> Dorian
>>
>
>
>
> --
> < Belaid >
>
>
>
>


--
< Belaid >

--089e013d1db2de4d6704e69117fa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div>Bonjour,<br></div>lsof permet de voir les fichiers qu=
i sont en cours d&#39;utilisations par les process. Par:<b> lsof | grep -i =
nom_de_ton_gros_fichier</b> je voulais être sur que ton gros fichier n&#3=
9;est pas encore en cours d&#39;utilisation (même supprimé un fichier p=
eut encore être présent sur le disque, et aussi sur mémoire s&#39;il =
est encore en cours d&#39;utilisation).<br>
<div><div><div class="gmail_extra"><br><br><div class="gmail_quote">Le =
17 septembre 2013 11:32, Dorian Carpentier de Changy <span dir="ltr">&lt;=
<a href="mailto:dechangydorian@yahoo.fr" target="_blank">dechangydorian=
@yahoo.fr</a>&gt;</span> a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">



<div text="#000000" bgcolor="#FFFFFF">
df -ih<br>
Sys.de fichiers    Inodes            IUtilisé=
        ILib.       
IUti%     Monté sur
<br>
/dev/sda5           598K           =
    163K          436K       
28%    /
<br>
tmpfs                   354K   =
             5              =
  354K  
        1%    /lib/init/rw
<br>
udev                     336K =
              892            335K=
  
         1%    /dev
<br>
tmpfs                   354K   =
                 2          =
  354K  
         1%    /dev/shm
    <br>
overflow              354K       =
             1            354K =
    
       1%    /tmp
<br>
<br>
L&#39;utilisation des Inodes montre que 72% sont inoccupés !?<div cla=
ss="im"><br>
<br>
Sys.de fichiers    1K-blocs        Utilisé  =
          Dispo.       
Uti%     Monté sur
<br>
/dev/sda5           9620408       96204=
08            0           
100%    /
<br>
tmpfs                    1449340=
                    0      14=
49340
    0%    /lib/init/rw
<br>
udev                      137=
3708               272       1373436=
  
  1%    /dev
<br>
tmpfs                    1449340=
                    0      =
 
1449340     0%    /dev/shm
<br>
overflow                     =
1024                    0     =
  
1024          0%    /tmp
<br>
<br>
<br>
<br>
<br>
</div><div>Le 16/09/2013 13:15, Johnny B a écrit :<br>
</div><div><div class="h5">
<blockquote type="cite">

<div>Salut,<br>
<br>
A tous les coups tu as tes inodes full<br>
<br>
Fais un df -ih<br>
<br>
Le 09/16/2013 12:40 PM, Belaïd MOUNSI a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>Bonjour,<br>
</div>
Que donne la commande suivante:<br>
</div>
lsof | grep -i le_nom_de_ton_fichier <br>
</div>
<div>
<div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">Le 16 septembre 2013 11:57,
Dorian <span dir="ltr">&lt;<a href="mailto:dechan=
gydorian@yahoo.fr" target="_blank">dechangydorian@yahoo.fr</a>&gt;</span>
a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="font-size:12pt;font-family:times ne=
w roman,new york,times,serif">
<div><span>Bonjour,</span></div>
<div> <span></span> </div>
<div><span>Suite à l&#39;encodage d&#39;un vi=
déo
sous PiTiVi, j&#39;ai obtenu un fichier qui
a occupé tt l&#39;espace disque restant(3=
.9G
sur un volume de 9G).</span></div>
<div><span>J&#39;ai souhaité supprimer le
fichier. puis Reboot. Lors de la
fermeture, le système freezais avant
d&#39;envoyer le TERM.</span></div>
<div><span>J&#39;ai forcé la fermeture par le
bouton power du portable.</span></div>
<div><span>JE redémarre et constate que j&#39=
;ai
accès que à la CLI.</span></div>
<div><span>df signale, 100% sur /dev/sda5
(le volume logique sur lequel est
installé Squeeze avec noyau Xen-4.0,
plusieurs LV créés mais inutilisés, i=
l y
a des messages d&#39;erreurs leur cc au
démarrage, à tt hazard)</span></div=
>
<div><span>J&#39;ai retrouvé le fichier qui =
à ma
connaissance (je n&#39;ai pas vérifier =
à
l&#39;ai de de ls -hla &lt;nom fichier&gt;)
et l&#39;ai supprimé rm.</span></div>
<div><span>Le  fichier n&#39;existe bien plus=
.
df m&#39;indique tjs 100% d&#39;utilisation=
sur
/dev/sda5. Mais je ne sais pas
comment/quel répertoire/fichier occupe
tt cet espace. </span></div>
<div><span>free m&#39;indique que le swap est
vide. ram utilisé à 10 %</span></div>
<div><span></span> </div>
<div><span></span> </div>
<div><span>Le texte qui s&#39;affiche au
lancement de la machine m&#39;affiche:</spa=
n></div>
<div><span>starting Avahi mDNS/DNS-SD Daemon
: avahi-daemon Failed!</span></div>
<div><span>uname: write error : No space
left on device</span></div>
<div><span>cat: write error : No space left
on device</span></div>
<div><span></span></div>
<div><span>Can&#39;t start hardware abstraction
layer - please ensure dbus is running
failed!</span></div>
<div> </div>
<div>Un init 5 ou init 3 ne me permet pas
rentrer ds la GUI.</div>
<div> </div>
<div>JE dois pouvoir retrouver le contrôle
sur la GUI, je mène un teste sur XEN.</div>
<div> </div>
<div>MErci de votre support,</div>
<span><font color="#888888">
<div> </div>
<div> </div>
<div>Dorian </div>
</font></span></div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
&lt; Belaid &gt; </div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</blockquote>
<br>
</div></div></div>

</blockquote></div><br><br clear="all"><br>-- <br>&lt; Belaid &gt;
</div></div></div></div>

--089e013d1db2de4d6704e69117fa--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/CAFuS2bbUXu4+25wLOV=iVzBu+Hj8Uxyn6ONYLWnzEk9W099H6A@mail.gmail.com
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Sébastien NOBILI
Le #25665782
Bonjour,

Le mardi 17 septembre 2013 à 12:35, Dorian Carpentier de Changy a écrit :
la REPERTOIRE /var/log et /var/tmp mesurent que 22M et 4K
respectivement. Mesuré avec du Nom_du_repertoire.
Est-ce vraiment utile? N'y a-t-il pas un danger à effacer ts les
logs?



Utile, visiblement pas (sauf à vouloir gagner 22Mo mais tu n'en es pas là).
Dangereux, sûrement ! Si tu suis toutes les pistes des gens qui te conseillent
de supprimer des choses sans même savoir ce qu'il se passe exactement sur ton
système, tu vas à la catastrophe !

En conclusion, prends le temps de chercher (notamment le « du -sh * » qui t'a
été conseillé par ailleurs) en ensuite, corrige lorsque tu es sûr d'avoir
identifié la cause.

qu'est ce qui effectue cette opération efficacement sur un
répertoire (rm * path/to/folder?)



Pour supprimer efficacement, c'est en effet rm .

Attention toutefois :
- dans ton exemple « rm * path/to/folder », tu vas supprimer *tous* les
éléments du dossier courant ! Si c'est la racine, tu es mal.
- tu ne peux pas revenir en arrière, prends tes précautions.
Personnellement :
- je déplace tout ce que je veux supprimer dans un dossier (toujours le
même), ce qui permet de vérifier une dernière fois avant suppression,
- j'utilise systématiquement des chemins absolus « rm
/chemin/vers/fichier »

Seb

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Johnny B
Le #25665852
Oui degager /var/log c'est pas toujours top faut mettre en place des
logrotate pour "entretenir" ses fichiers de logs.

T as surement un symlink ou un truc en cache qui fou le bordel, t'aurais
pas renommé ton dossier au lieu de le supprimer par hasard ? ;)

Le 09/17/2013 01:04 PM, Dorian Carpentier de Changy a écrit :
J'étais pas sur le point de rm * /var/log, une rapide recherche sur
wwww m'a averti du danger sans apporter de méthode.
Merci pour l'enseignement des bonnes pratiques à suivre.
Je mémorise et conserve, utile pour un bleu comme moi.
:-)
Le 17/09/2013 12:53, Sébastien NOBILI a écrit :
Bonjour,

Le mardi 17 septembre 2013 à 12:35, Dorian Carpentier de Changy a
écrit :
la REPERTOIRE /var/log et /var/tmp mesurent que 22M et 4K
respectivement. Mesuré avec du Nom_du_repertoire.
Est-ce vraiment utile? N'y a-t-il pas un danger à effacer ts les
logs?


Utile, visiblement pas (sauf à vouloir gagner 22Mo mais tu n'en es
pas là).
Dangereux, sûrement ! Si tu suis toutes les pistes des gens qui te
conseillent
de supprimer des choses sans même savoir ce qu'il se passe exactement
sur ton
système, tu vas à la catastrophe !

En conclusion, prends le temps de chercher (notamment le « du -sh * »
qui t'a
été conseillé par ailleurs) en ensuite, corrige lorsque tu es sûr
d'avoir
identifié la cause.

qu'est ce qui effectue cette opération efficacement sur un
répertoire (rm * path/to/folder?)


Pour supprimer efficacement, c'est en effet rm .

Attention toutefois :
- dans ton exemple « rm * path/to/folder », tu vas supprimer
*tous* les
éléments du dossier courant ! Si c'est la racine, tu es mal.
- tu ne peux pas revenir en arrière, prends tes précautions.
Personnellement :
- je déplace tout ce que je veux supprimer dans un dossier
(toujours le
même), ce qui permet de vérifier une dernière fois avant
suppression,
- j'utilise systématiquement des chemins absolus « rm
/chemin/vers/fichier »

Seb







--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Sébastien NOBILI
Le #25665982
Le mardi 17 septembre 2013 à 12:58, Dorian Carpentier de Changy a écrit :
Reçu,
3.6G sur /usr (pas d'avertissement)
4.3G sur /home/dorian > ,en l'associant à ts ses sous-répertoires
(hors les cachés style .cache etc) j'obtiens
197M sur /home/dorian/Vidéos effectivement le répertoire où était
conservé le fichier cible. C le seul répertoire avec un volume
conséquent. MAis ce fichier n'existe plus à sa destination
cette analyse a le mérite d'avoir mis en avant que 4.1 G sont
présents mais (je crois que lors de la suppression du fichier il
faisait 3.9G) il n'est pas repris dans la vue .



Qu'entends-tu par « mis en avant que 4,1G sont présents » ?
- que la somme des espaces occupés fait 4,1G de moins que la taille de la
partition ?
- que ton système t'indique qu'il y a bien 4,1G de libre ?

Seb

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Publicité
Poster une réponse
Anonyme