Vous n'êtes pas identifié(e).
Pages : 1
Dernière modification par Elou-end (12-10-2021 11:19:03)
Hello, j'utilise Debian depuis un petit moment mais j'arrive toujours à me retrouver dans le pétrin ^^'
Hors ligne
une partition temporaire et anormalement pleine (/var/tmp il me semble)
Il est rare qu'une partition entière soit dédiée à /var/tmp. Plutôt /tmp ou /var.
je me dis qu' un petit reboot ferai du bien et viderai un peu cette partition pleine.
/var/tmp n'est pas vidé au redémarrage. Cf. définition du FHS.
On va supposer que le problème est causé par le manque d'espace disque libre quelque part et faire une petite analyse de l'occupation.
Refaire la seconde commande pour chaque point de montage d'une partition (affiché par df) puis les sous-répertoires les plus volumineux, par exemple
si /var est un point de montage ou volumineux,
si /var/cache est volumineux, etc.
Dernière modification par raleur (12-10-2021 19:32:30)
Il vaut mieux montrer que raconter.
Hors ligne
Mais il me semble que j'avais déjà cette erreur avant et que tous fonctionnait normalement.
Et à la suite de la ligne précédente avec dev/sda10 la partition la partition sur laquelle il y'a mon système:
Hello, j'utilise Debian depuis un petit moment mais j'arrive toujours à me retrouver dans le pétrin ^^'
Hors ligne
je ne parlé pas d'une partition mais du dossier /var/tmp
Un répertoire ne peut pas être "anormalement plein" (ni normalement d'ailleurs). Il n'a pas de taille limite, c'est la taille du système de fichiers qui le contient.
Pour les commande, est-ce que je peux les lancer depuis un live USB ou ça ne marchera pas comme il faut.
Il faudra monter les partitions une par une et ajouter le point de montage au chemin des commandes du. Mais tu n'as pas besoin de système live, tu peux aussi bien démarrer en mode recovery.
je n'ai pas accès à un terminal
Alors pourquoi avoir écrit ça ?
Je n'ai pas non plus accès aux bureau en ligne de commande.
qui laissait penser que tu avais accès à la ligne de commande ?
5834607/6144000 blocks
Soit quasiment 5% d'espace libre, ce qui est l'espace réservé à root par défaut. Cela signifie qu'un utilisateur non root (y compris celui avec lequel tourne le gestionnaire de connexion) ne peut plus faire d'écriture nécessitant d'allouer de l'espace disque sur cette partition.
Il vaut mieux montrer que raconter.
Hors ligne
Mais tu n'as pas besoin de système live, tu peux aussi bien démarrer en mode recovery.
Le recovery lui aussi ne fonctionne pas. J'ai donc essayer les commande avec un live os que j'avais sous la main.
Avec 63d48522-f30f-481f-95a3-494adf3f3d39 la partiton système de mon PC
Est-ce que si le dossier /var fait 13G c'est "normal" ou c'est anormalement volumineux?
Lib est bien plein mais c'est surtout à cause de snap qui prend 4Go.
Est ce que c'est normal d'avoir des fichier log aussi volumineux ?
Cela signifie qu'un utilisateur non root (y compris celui avec lequel tourne le gestionnaire de connexion) ne peut plus faire d'écriture nécessitant d'allouer de l'espace disque sur cette partition.
Est-ce que cela signifie que si j'augmente la taille de ma partition systeme linux fonctionnemera de nouveau ?
Dernière modification par Elou-end (14-10-2021 22:01:55)
Hello, j'utilise Debian depuis un petit moment mais j'arrive toujours à me retrouver dans le pétrin ^^'
Hors ligne
Le recovery lui aussi ne fonctionne pas
Pourquoi ? Que se passe-t-il ?
Cela ne peut pas être à cause de l'espace disque libre, il reste les 5% réservés à root. Et même avec une racine pleine à 100%, je ne pense pas que cela empêche d'utiliser le mode recovery.
Est ce que c'est normal d'avoir des fichier log aussi volumineux ?
Non, à moins qu'ils ne "tournent" jamais (absence de fichiers .1, .2...)
Quelque chose écrit de façon effrénée dans les logs. Vu les fichiers concernés, a priori il ne s'agit pas de messages du noyau mais d'un programme de la session utilisateur ou du gestionnaire de connexion.
Je te dirais bien de regarder dans l'un d'eux (il y a les mêmes messages répétitifs dans les trois), mais il peut être délicat d'afficher le contenu d'un fichier aussi volumineux, il faut bien choisir son programme (un "pager" comme less plutôt qu'un éditeur de texte). Le plus simple serait de supprimer ces trois fichiers puis de surveiller leur taille. S'ils grossissent rapidement à nouveau, il faudra regarder le contenu de l'un d'eux pour essayer d'en trouver l'origine.
Est-ce que cela signifie que si j'augmente la taille de ma partition systeme linux fonctionnemera de nouveau ?
Cela ne sera que temporaire si les logs continuent à grossir.
Dernière modification par raleur (14-10-2021 23:41:15)
Il vaut mieux montrer que raconter.
Hors ligne
je ne pense pas que cela empêche d'utiliser le mode recovery.
Je ne sais pas pourquoi mais je ne pouvais pas utiliser le recovery non plus.
Non, à moins qu'ils ne "tournent" jamais (absence de fichiers .1, .2...)
Si ils existent bien et sont moins volumineux (max 600 ko).
Les fichiers messages, syslog et user.log ont étaient modifier entre le 26/09 et le 12/10 se qui fait à peut près 3 semaines et pèse chacun 2Go, se qui fait beaucoup de log en peu de temps.
Ps: Je ne suis pas tout à fait sûr que les commandes utiliser si dessous donne les résultats que j'attens (en teme d'interprétation) car je ne suis pas un expert en shell ^^'
J'ai commencé par vouloir connaitre leurs tailles en terme de ligne:
Puis j'ai effectué des recherches avec des mots clés qui visiblement appaissait régulierement. J'aurrais aimé trouver une commande donnant le mots qui avec le plus d'ocurence mais visiblement ça n'existe pas.
Comme c'est pas vraiment parlant, j'ai fait transformé le nombre obtenu en pourcentage par rapport au nombre de ligne du document.
Visiblement ce sont des extentions shell que j'ai installer qui sont à l'origine de ces gros fichier log.
Pour etre précis c'est gsconnect une extention pour connecter son smartphone et son PC. Ce qui est surprennant c'est que c'est la premiere fois que j'observe cela alors que j'utilise l'extention depuis quelque temps.
De plus un autre élement est récurent :
Avec par exemple la ligne dans le fichier log, message : gjs[1752]: ../../../gobject/gsignal.c:2642: instance '0x55ecf11b8cd0' has no handler with id '183'
Mais je ne sais pas à quoi ça correspond...
J'ai chercher des trace de gsconnect dans les 2 autre fichier log volumineux :
Donc l'extention gnom shell gsconnect à visiblement génere 72% des lignes des fichiers log volumineux et serais la cause de la saturation de la memoire.
Et aprés verificaon "gjs" apparait aussi 18% du temps dans les fichier log volumineux.
Hello, j'utilise Debian depuis un petit moment mais j'arrive toujours à me retrouver dans le pétrin ^^'
Hors ligne
cat /media/kali/63d48522-f30f-481f-95a3-494adf3f3d39/var/log/messages | wc -l
UUoC (usage inutile de cat)
cat /media/kali/63d48522-f30f-481f-95a3-494adf3f3d39/var/log/messages | grep "gnome-shell" | wc -l
Usage inutile de cat et de wc.
sudo echo $((100*$(sudo cat /media/kali/63d48522-f30f-481f-95a3-494adf3f3d39/var/log/messages | grep "gnome-shell" | wc -l)/10122849))
Usage inutile de sudo (le premier), de cat et de wc.
Visiblement ce sont des extentions shell que j'ai installer qui sont à l'origine de ces gros fichier log.
Pour etre précis c'est gsconnect une extention pour connecter son smartphone et son PC
Comment l'as-tu installée ? Avec un paquet Debian officiel ?
Il vaut mieux montrer que raconter.
Hors ligne
Comment l'as-tu installée ? Avec un paquet Debian officiel ?
Non j'ai installé l’extension depuis extensions.gnome.org ou Logiciel (l’installateur de paquet graphique par défaut dans Debian), je ne sais plus trop.
Je pourrais essayer de l'installer depuis le dépôt officiel et pas passer par une extension directement.
Après je sais pas si on peut parler de dépôt officiel car c'est un paquet KDE et non Debian.
J'ai d’ailleurs supprimer les fichiers log trop volumineux (en gardant une achive) et désactiver l'extension le temps de trouver une solution et mon système fonctionne de nouveau.:D
Hello, j'utilise Debian depuis un petit moment mais j'arrive toujours à me retrouver dans le pétrin ^^'
Hors ligne
Pages : 1