[résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

Herve5 · 09-05-2021 21:05:11

Bonjour à tous pour ce post écrit, honte ultime, depuis un PC win...
A la suite du visionnage d'un film assez long fraîchement téléchargé, au reboot juste après le GUI log/pass j'ai un message annonçant qu'il est impossible d'écrire dans /tmp, puis exit le GUI faute de place manifestement.
je démarre donc en "recovery" et un df -h indique effectivement 100% d'occupation du volume associé à / (pas les autres)
Je connais très peu de commandes terminal

et manifestement, celle qui fut efficace il y a quelques mois, une purge avec apt-get clean (et autoclean) ne suffit pas.
Que me conseilleriez-vous?

D'avance merci!!
Hervé

Dernière modification par Herve5 (11-05-2021 14:53:57)

raleur · 09-05-2021 21:38:15

Analyse de l'occupation de l'espace disque. On commence par

df -h /

du -hxd1 / | sort -h

On vérifie la cohérence entre les deux, et on poursuit dans les répertoires les plus volumineux. Par exemple si c'est /var :

du -hxd1 /var | sort -h

et ainsi de suite, en espérant identifier un gros contenu.
Pas la peine de chercher dans /usr, il n'y a normalement rien à supprimer là-dedans sauf en désinstallant des paquets.

Dernière modification par raleur (09-05-2021 21:39:42)

Herve5 · 10-05-2021 08:37:12

Merci Raleur!
Je commence et j'obtiens successivement ceci :

puis

Je note un énorrrrme fichier "daemon.log" par exemple... Comment je purge ça proprement? J'ai entendu parler de la commande logrotate, mais elle est bien compliquée pour moi...

jpt · 10-05-2021 09:35:23

Bonjour,

Herve5 a écrit :

Je note un énorrrrme fichier "daemon.log" par exemple... Comment je purge ça proprement?

Quand on est plein à 100% et qu'on ne peut plus bosser, on oublie le "proprement" et on fait en mode "à la rache", genre ce fichier, tu le supprimes purement et simplement. Complètement, sans passer par la corbeille (car sinon il n'est pas supprimé, il est juste caché).

Ceci dit, entre un home plein à 84% et un stockphoto à 90%, je pense que tu n'iras pas bien loin dans pas longtemps, à moins que tu ne rajoutes un disque.

Et enfin, coup de gueule personnel, je ne comprends pas qu'un OS qui se prétend évolué et "au top" n'implémente pas par défaut un système de surveillance de l'espace disque libre. C'est comme si les constructeurs de bagnoles fourguaient leurs caisses sans jauge du réservoir de carburant, c'est profondément débile. Oui, je sais, il y a plein d'outils qui le font, et on voit où ça mène…

Tawal · 10-05-2021 09:43:01

Je suis bien d'accord !

jpt a écrit :

Et enfin, coup de gueule personnel, je ne comprends pas qu'un OS qui se prétend évolué et "au top" n'implémente pas par défaut un système de surveillance de l'espace disque libre. C'est comme si les constructeurs de bagnoles fourguaient leurs caisses sans jauge du réservoir de carburant, c'est profondément débile. Oui, je sais, il y a plein d'outils qui le font, et on voit où ça mène…

D'où la présence d'un conky sur mon bureau ...

Herve5 · 10-05-2021 09:59:00

jpt a écrit :

(...) Ceci dit, entre un home plein à 84% et un stockphoto à 90%, je pense que tu n'iras pas bien loin dans pas longtemps, à moins que tu ne rajoutes un disque.

home est plein parce que j'ai installé provisoirement une machine virtuelle macintosh pour récupérer de très vieux fichiers ; stockphoto, ma foi, ce sont des photos, donc ça se remplit lentement.
Mais effectivement ma machine étant compatible de trois disques, je prévois de compléter. Ce qui me retient encore c'est que j'hésite entre un disque SSD de plus (qui ne dépassera jamais 2T pour très cher) et un "classique" où je pourrais mettre 8T mais dont je crains qu'il ne consomme plus d'énergie.

Autrement, comme j'ai accès au terminal (sans serveur X), ce que je cherche c'est précisément comment purger mon gros fichier log sans le détruire, pour ne pas planter un process ou un autre, et aussi pour "trouver le coupable" qui m'abreuve d'entrées là-dedans. Je pense qu'il faut lancer logrotate avec les bonnes options, mais c'est ça que je ne sais pas faire...

jpt · 10-05-2021 10:07:17

Herve5 a écrit :

comment purger mon gros fichier log sans le détruire

echo "" > /var/log/daemon.log

Tawal a écrit :

D'où la présence d'un conky sur mon bureau ...

qui n'est pas installé de base, on est d'accord ? Et qu'il faut sans doute paramétrer/configurer (je suppose, je n'ai pas de conky) pour qu'il fasse le taf ?
As-tu remarqué que dans ta bagnole, quand le niveau de mol' descend trop bas, y a une loupiote qui te le signale sans que tu n'aies rien configuré ?

Dernière modification par jpt (10-05-2021 10:10:34)

Herve5 · 10-05-2021 10:21:04

Merci jpt, mais est-ce que je comprends correctement que cette commande-là va vider complètement le log?
Ce que j'aimerais c'est en liquider 90% mais en gardant mettons les 1000 dernière lignes, par exemple.
Je réfléchis à une combinaison de tail et echo mais je ne suis pas trop malin, peut-être un tail qui copierait ailleurs ces 1000 dernières avant l'echo...

Herve5 · 10-05-2021 10:28:57

Allez, je m'en vais essayer

tail -n 5000 daemon.log > /dansundossieroùyad'lapace/fichierdaemonfautif.log

puis effectivement

echo "" > /var/log/daemon.log

[edit] Bien, ça semble avoir marché, et X démarre, mais après l'excitation "Qu'il est beau mon fond d'écran retrouvé", j'ai parfaitement conscience que je n'ai absolument pas résolu mon problème. Je m'en vais regarder ce foutu log, mais ce n'est peut-être même pas là que ça ne va pas?
Désormais,

~$ df -h

df: /run/user/1000/doc: Opération non permise

Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur

udev               7,7G       0  7,7G   0% /dev

tmpfs              1,6G    1,8M  1,6G   1% /run

/dev/nvme0n1p5      28G     22G  4,7G  83% /

tmpfs              7,7G    217M  7,5G   3% /dev/shm

tmpfs              5,0M    4,0K  5,0M   1% /run/lock

/dev/nvme0n1p7     1,7T    1,4T  269G  84% /home

/dev/nvme0n1p1     256M     60M  197M  24% /boot/efi

/dev/sda1          1,8T    1,6T  186G  90% /home/herve/stockphoto

tmpfs              1,6G     76K  1,6G   1% /run/user/1000

[edit 2] Bon, ben j'ai ratu : les 5000 dernières lignes du log contiennent dès le début des annonces du genre "LinuxHerve Tor[955]: Error writing to "/var/lib/tor/state": No space left on device", donc le truc était plein déà à ce moment-là. J'aurais dû tout sauvegarder ailleurs...

Dernière modification par Herve5 (10-05-2021 11:07:36)

raleur · 10-05-2021 12:04:53

Tu n'as pas mené l'exploration à son terme, tu t'es arrêté au premier niveau de l'arborescence (la racine) et tu as sauté directement dans /var/log sans même regarder ce qu'il y avait dans /var. Tu as vidé un fichier de 6 Go, mais l'espace occupé par /var était 13 Gio, on est donc loin du compte.

Il n'est pas rare que les mêmes messages soient écrits dans plusieurs fichiers de log tels que daemon.log, messages, syslog, kern.log... Il reste donc probablement un autre fichier dont tu peux examiner le contenu avant de le vider. Mais il n'est pas toujours facile de manipuler un fichier texte de plusieurs giga-octets.

De toute façon, si la cause des messages persiste, tu vas les retrouver dans les nouveaux logs. Apparemment c'est récent puisque le fichier messages.1 qui s'étend du 2 au 9 mai a une taille raisonnable.

Dernière modification par raleur (10-05-2021 12:07:48)

Herve5 · 10-05-2021 12:12:39

Merci raleur, je prévoyais en effet de continuer l'enquête!
J'ai en outre /var/log/syslog qui pèse 6Go, et apparemment en un seul jour (est-ce que j'interprète bien?) :

~$ ls -l /var/log

total 5680716

-rw-r--r--  1 root              root                  8967  4 mai   07:59 alternatives.log

(...)

drwx------  2 speech-dispatcher root                  4096 26 avril  2020 speech-dispatcher

-rw-r-----  1 root              adm             5804828012 10 mai   13:17 syslog

-rw-r-----  1 root              adm                4247541  9 mai   08:43 syslog.1

drwxr-xr-x  2 root              root                  4096 31 oct.   2020 sysstat

(...)

Ma question : avant de lui faire subir un echo "" > /var/log/syslog , est-il utile d'en garder un morceau (plus gros que les 5000 lignes inutiles que j'avais prises sur daemon.log)?

Merci encore!

Dernière modification par Herve5 (10-05-2021 12:24:30)

Tawal · 10-05-2021 12:30:34

Hello,

Tu devrais le sauvegarder ailleurs, le splitter et l'examiner.
Mais comme dit raleur, le souci est récent. Il fort probable que certains logs regonflent.
À surveiller donc ...

Herve5 · 10-05-2021 12:37:41

copié, vidé, pas encore analysé, mais déjà mon encombrement est devenu plus correct à 62% sur / :

# df -h

Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur

udev               7,7G       0  7,7G   0% /dev

tmpfs              1,6G    1,8M  1,6G   1% /run

/dev/nvme0n1p5      28G     16G   11G  62% /

tmpfs              7,7G    381M  7,4G   5% /dev/shm

tmpfs              5,0M    4,0K  5,0M   1% /run/lock

/dev/nvme0n1p7     1,7T    1,4T  269G  84% /home

/dev/nvme0n1p1     256M     60M  197M  24% /boot/efi

/dev/sda1          1,8T    1,6T  175G  91% /run/timeshift/backup

tmpfs              1,6G     80K  1,6G   1% /run/user/1000

Une remarque qui n'a sans doute rien à voir : je note que /dev/sda1 n'est plus "monté sur" le même point que plus haut, je ne m'explique pas pourquoi... (il a gonflé un peu parce que j'ai recopié dessus le syslog, ça c'est normal)

Dernière modification par Herve5 (10-05-2021 12:48:53)

raleur · 10-05-2021 12:38:18

Tu peux le copier dans /home pour examen ultérieur.

anonyme · 10-05-2021 12:52:28

Bonjour,

jpt a écrit :

Et enfin, coup de gueule personnel, je ne comprends pas qu'un OS qui se prétend évolué et "au top" n'implémente pas par défaut un système de surveillance de l'espace disque libre.

À défaut il y a logrotate.

Herve5 · 10-05-2021 12:53:09

raleur a écrit :

Tu peux le copier dans /home pour examen ultérieur.

Je l'ai copié dans le second disque "stockphoto" effectivement, ce qui a donné le changement bizarre de point de montage (!) que je viens de commenter dans mon post précédent.
Pour l'instant, en regardant les dernières heures et (moi qui n'y connais rien) en recherchant dedans le mot "warning", je trouve une ligne répétée pas mal de fois qui concerne apparemment les pilotes non-free Nvidia, qui sont updatés régulièrement; cette ligne dit :
May 10 11:42:15 LinuxHerve kernel: [12540.669263] nvidia-modeset: WARNING: GPU:0: BOE Technology Group Co., Ltd (DP-3): G-SYNC Compatible: EDID min refresh rate invalid, disabling G-SYNC Compatible.

Dernière modification par Herve5 (10-05-2021 12:58:11)

Herve5 · 10-05-2021 12:56:13

Tux12 je pense effectivement à logrotate; sur ce sujet ma question serait : puis-je éditer mon fichier logrotate.conf en ajoutant froidement dedans une ligne
size 10M
par exemple après
weekly
rotate 4
Ca ne résoud pas le reste, mais ça permet de respirer...

Dernière modification par Herve5 (10-05-2021 12:57:39)

Tawal · 10-05-2021 18:40:33

Pour logrotate, je ne sais pas trop, alors je ne te dirais rien.

Mais pour "splitter" le fichier, tu peux regarder la commande split, qui permet de "découper" un fichier en plusieurs avec un nombre donné de lignes par fichier.ainsi chaque "morceau" sera bien facile à ouvrir/analyser.

Edit: split peut aussi découper avec une taille donnée en octets par fichiers, ce qui est plus facile pour estimer le nombre de fichiers qui vont être créés.
..

Dernière modification par Tawal (10-05-2021 18:44:41)

Herve5 · 11-05-2021 12:33:32

Bon, je viens de tenter un maxsize 1234K dans logrotate.conf, dans l'idée que lorsque ce plafond sera touché, je vais pouvoir le voir rien qu'en regardant la taille des fichiers... on va bien voir

[edit] Bon, ça marche bien : en forçant un sudo logrotate -f /etc/logrotate.conf je vois sous mes yeux éblouis les syslog et messages se découper chacun en un vieux morceau de 1234K et un nouveau plus petit.

Il me reste encore à vérifier des trucs (j'ai changé deux fichiers, le logrotate.conf et aussi /etc/logrotate.d/rsyslog parce que ça ne marchait pas (alors qu'en fait j'écrivais "1234K" au lieu de 1234k

)
...mais je tiens le bon bout.

Merci à tous!!
je marque en [résolu] bien que je n'aie toujours pas trouvé qui est le coupable qui a suscité tout ce bazar dans les logs (je continue à chercher) mais de fait le sujet "X ne démarre pas" (faute de place) est effectivement résolu...

Dernière modification par Herve5 (11-05-2021 15:03:06)

Herve5 · 11-05-2021 18:06:30

jpt a écrit :

(...) Et enfin, coup de gueule personnel, je ne comprends pas qu'un OS qui se prétend évolué et "au top" n'implémente pas par défaut un système de surveillance de l'espace disque libre. C'est comme si les constructeurs de bagnoles fourguaient leurs caisses sans jauge du réservoir de carburant, c'est profondément débile. Oui, je sais, il y a plein d'outils qui le font, et on voit où ça mène…

JPT je reviens sur ce point, car je viens de trouver ceci : https://linoxide.com/check-disk-usage-is-out-of-space/ que je n'ai pas encore testé. Je comprends que ça reste assez simple mais je n'ai pas la sensation que ce soit une "alerte automatique", mais plutôt un truc à lancer soi-même...

anonyme · 11-05-2021 18:44:43

Bonjour,

Désolé Hervé5, j''ai préféré ne pas répondre à propos de logrotate car je ne le connais pas assez pour répondre avec certitude. De toute façon et comme tu le dis ce n'est pas LA solution car ça n'est pas forcément applicable à tous les fichiers.
J'avais réagi en fait par rapport à la plainte de jpt car je ne vois pas comment un système composé de parties développées de façon indépendantes et interchangeables peut répondre à la demande; autant du et df sont "universels" en console, autant dès lors que l'on choisit un interface graphique parmis des dizaines il me paraît optimiste de penser que chacun d'entre eux intègrera une solution de suivi de gestion de l'espace disque, et déplacé d'en reprocher l'absence au système.

Du coup je viens de regarder vite fait pour voir s'il existe un paquet qui puisse répondre à la demande d'un gestionnaire d'espace disque pour XFCE et je vois qu'il existe un paquet baobab qui semble correspondre à la demande. À défaut de gérer l'espace ça peut peut-être au moins permettre d'être averti dès lors qu'on atteint un seuil. À tester donc peut-être?

Herve5 · 11-05-2021 18:56:53

tux12 a écrit :

(...) Du coup je viens de regarder vite fait pour voir s'il existe un paquet qui puisse répondre à la demande d'un gestionnaire d'espace disque pour XFCE et je vois qu'il existe un paquet baobab qui semble correspondre à la demande. À défaut de gérer l'espace ça peut peut-être au moins permettre d'être averti dès lors qu'on atteint un seuil. À tester donc peut-être?

Mais (étant aussi sur XFCS) ça semble très intéressant, ça! Je vais regarder aussi!
Merci!
H.
[edit] Ah, je vois, apparemment c'est une version à graphe arrondi de ce que fait, sous forme de rectangles, Qdirstat (https://github.com/shundhammer/qdirstat … e-packages). Ce dernier ne déclenche pas d'alarme, c'est plutôt un outil pour identifier les gros fichiers oubliés par exemple (et on peut même les effacer à partir de son interface). Je vais regarder Baobab de plus près.

Dernière modification par Herve5 (11-05-2021 19:03:55)

jpt · 12-05-2021 08:31:31

Bonjour,

tux12 a écrit :

J'avais réagi en fait par rapport à la plainte de jpt car je ne vois pas comment un système composé de parties développées de façon indépendantes et interchangeables peut répondre à la demande;

On implémente ça dans le noyau, à charge pour les superbes applis graphiques d'aller récupérer l'info et faire ce qu'il faut avec.
D'ailleurs ça fonctionne comme ça pour les températures (des disques, du proc, etc.)

Tawal · 12-05-2021 10:21:56

Hello,

jpt a écrit :

Oui, je sais, il y a plein d'outils qui le font, et on voit où ça mène…

Lesquels ?

tux12 a écrit :

Du coup je viens de regarder vite fait pour voir s'il existe un paquet qui puisse répondre à la demande d'un gestionnaire d'espace disque pour XFCE et je vois qu'il existe un paquet baobab qui semble correspondre à la demande ...

C'est plutôt une usine à gaz pour juste le problème de surveillance des espaces disques, non ?

Mais même avec de l'espace disque disponible (c'est mon cas Partition racine : 20Go, système : 12Go), je trouve dommageable qu'il n'y ait pas un système implémenté de base pour éviter les "spams" dans les logs. Car je trouve que le cas des logs qui gonflent revient assez souvent.
.

Herve5 · 12-05-2021 13:00:11

Tawal a écrit :

Mais même avec de l'espace disque disponible (c'est mon cas Partition racine : 20Go, système : 12Go), je trouve dommageable qu'il n'y ait pas un système implémenté de base pour éviter les "spams" dans les logs. Car je trouve que le cas des logs qui gonflent revient assez souvent.

Avec logrotate je viens de résoudre ce point des logs (sans pour autant trouver ce qui les fait gonfler). Sur l'alerte automatique une recherche donne un tas de scripts à répéter en cron et qui généralement t'envoient un mail; par exemple ci-dessous. Mais je n'en ai encore implanté aucun...
https://www.2daygeek.com/linux-shell-sc … end-email/
https://bash.cyberciti.biz/monitoring/s … diskspace/
https://www.linux.com/training-tutorial … end-email/
https://linoxide.com/check-disk-usage-is-out-of-space/

Debian-facile

#1 09-05-2021 21:05:11

[résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#2 09-05-2021 21:38:15

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#3 10-05-2021 08:37:12

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#4 10-05-2021 09:35:23

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#5 10-05-2021 09:43:01

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#6 10-05-2021 09:59:00

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#7 10-05-2021 10:07:17

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#8 10-05-2021 10:21:04

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#9 10-05-2021 10:28:57

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#10 10-05-2021 12:04:53

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#11 10-05-2021 12:12:39

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#12 10-05-2021 12:30:34

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#13 10-05-2021 12:37:41

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#14 10-05-2021 12:38:18

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#15 10-05-2021 12:52:28

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#16 10-05-2021 12:53:09

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#17 10-05-2021 12:56:13

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#18 10-05-2021 18:40:33

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#19 11-05-2021 12:33:32

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#20 11-05-2021 18:06:30

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#21 11-05-2021 18:44:43

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#22 11-05-2021 18:56:53

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#23 12-05-2021 08:31:31

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#24 12-05-2021 10:21:56

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

#25 12-05-2021 13:00:11

Re : [résolu] X ne démarre pas, / est plein, apt-get clean ne suffit pas

Pied de page des forums