/var quasiment plein [RÉSOLU]

fred02840 · 15-09-2022 14:16:48

Bonjour
Mon disque dur de 500 Go a été découpé automatiquement (autant que je m'en souvienne) en plusieurs partitions, lors de l'installation de la Debian, sans retouche de ma part. /var a reçu 7 Go.

Ce matin, une notification m'informe que sa limite est bientôt atteinte. Voici le détail des opérations pratiquées pour savoir ce que contient cette partition :

root@debian:~# du -hxd1 /var | sort -h

4,0K  /var/local

4,0K  /var/opt

16K /var/lost+found

148K  /var/mail

592K  /var/spool

22M /var/backups

181M  /var/cache

845M  /var/tmp

1,8G  /var/lib

6,3G  /var/log

9,1G  /var

Regardons dans /var/log

oot@debian:~# du -hxd1 /var/log | sort -h

4,0K  /var/log/gdm3

4,0K  /var/log/private

4,0K  /var/log/speech-dispatcher

4,0K  /var/log/tor

4,0K  /var/log/unattended-upgrades

12K /var/log/runit

48K /var/log/exim4

596K  /var/log/cups

992K  /var/log/apt

15M /var/log/installer

737M  /var/log/journal

6,3G  /var/log

Et dans les deux goinfres :

root@debian:~# du -hxd1 /var/log/installer | sort -h

14M /var/log/installer/cdebconf

15M /var/log/installer

root@debian:~# du -hxd1 /var/log/journal | sort -h

737M  /var/log/journal

737M  /var/log/journal/71a29335b93242c78011e930633f2156

Bien sûr, tout a été nettoyé comme il se doit : aptitude clean, aptitude autoclean, etc. C'est un nettoyage que je fais d'ailleurs chaque jour ; une sorte d'hygiène, en quelque sorte… Plus grand chose à gratter de ce côté-là. Sauf que `apt-get` me donne une autre version des choses

root@debian:~# apt-get clean

root@debian:~# apt-get autoclean

Lecture des listes de paquets... Erreur !

E: Erreur d'écriture - write (28: Aucun espace disponible sur le périphérique)

E: Erreur d'entrée/sortie lors de la sauvegarde du fichier de cache des sources

E: Les listes de paquets ou le fichier « status » ne peuvent être analysés ou lus.

Et maintenant, `aptitude autoclean` me tient le même langage, n'hésitant pas à se contredire sans aucune vergogne par rapport à mon inspection matutinale…

Qu'en pensez-vous ?

Ma première intention aurait été d'augmenter la taille de /var, ce qui n'est pas la meilleure idée qui soit… L'autre, radicale, serait de réinstaller la Debian, en prenant soin d'attribuer 10 Go à /var. Mais bon, c'est une perspective qui ne m'enchante guère…

Merci d'avance pour vos réponses

Dernière modification par fred02840 (16-09-2022 18:12:52)

vv222 · 15-09-2022 14:56:29

fred02840 a écrit :

Regardons dans /var/log

oot@debian:~# du -hxd1 /var/log | sort -h
4,0K /var/log/gdm3
4,0K /var/log/private
4,0K /var/log/speech-dispatcher
4,0K /var/log/tor
4,0K /var/log/unattended-upgrades
12K /var/log/runit
48K /var/log/exim4
596K /var/log/cups
992K /var/log/apt
15M /var/log/installer
737M /var/log/journal
6,3G /var/log

Ça nous montre que le problème n’est ni avec /var/log/journal ni avec /var/log/installer, mais avec des fichiers de taille déraisonnable directement à la racine de /var/log.

---

fred02840 a écrit :

Ma première intention aurait été d'augmenter la taille de /var, ce qui n'est pas la meilleure idée qui soit… L'autre, radicale, serait de réinstaller la Debian, en prenant soin d'attribuer 10 Go à /var. Mais bon, c'est une perspective qui ne m'enchante guère…

Et pourquoi pas tout simplement ne pas utiliser de partition dédiée pour /var ? À quoi sert-elle dans le cas présent ?

saitama-san · 15-09-2022 17:05:32

si /var/log est aussi gros, il faudrait penser à une rotation des logs
tu peux commencer avec :

journalctl --vacuum-size=100M

journalctl --vacuum-time=10d

Et pourquoi pas tout simplement ne pas utiliser de partition dédiée pour /var ? À quoi sert-elle dans le cas présent ?

ça ne règlera pas la source du problème

vv222 · 15-09-2022 17:40:01

Ce n’est pas utile de modifier les réglages de journald via journalctl. Les retours de commandes partagés dans le premier message montrent que ce ne sont pas les logs gérés par journald qui ont grossi hors de proportion.

saitama-san · 15-09-2022 18:01:09

vv222 a écrit :

Ce n’est pas utile de modifier les réglages de journald via journalctl. Les retours de commandes partagés dans le premier message montrent que ce ne sont pas les logs gérés par journald qui ont grossi hors de proportion.

si la partition est pleine, on commence par libérer de l'espace.
aucun intérêt de garder autant de log.

je propose en fonction des éléments à ma disposition mais si tu as mieux à proposer

raleur · 15-09-2022 18:28:24

fred02840 a écrit :

/var a reçu 7 Go.

Peu probable car il contient plus de 9 Go.

fred02840 a écrit :

Ma première intention aurait été d'augmenter la taille de /var, ce qui n'est pas la meilleure idée qui soit

En effet ce n'est probablement pas utile car 6 Go dans /var/log ce n'est pas normal. Une meilleure idée est de regarder pourquoi il y a 6 Go de logs puis nettoyer.

vv222 a écrit :

Et pourquoi pas tout simplement ne pas utiliser de partition dédiée pour /var ? À quoi sert-elle dans le cas présent ?

A éviter que les logs débordent dans la racine et causent des problèmes plus graves.

saitama-san a écrit :

si la partition est pleine, on commence par libérer de l'espace.

Non, on commence par regarder pourquoi les logs sont si volumineux, sinon le problème risque de revenir rapidement.
Soit la rotation ne se fait pas, soit une anomalie génère beaucoup de logs.
Les suspects habituels sont kern.log*, syslog*, messages*, daemon.log*.

saitama-san · 15-09-2022 18:49:06

raleur a écrit :

saitama-san a écrit :
si la partition est pleine, on commence par libérer de l'espace.

Non, on commence par regarder pourquoi les logs sont si volumineux, sinon le problème risque de revenir rapidement.
Soit la rotation ne se fait pas, soit une anomalie génère beaucoup de logs.
Les suspects habituels sont kern.log*, syslog*, messages*, daemon.log*.

retrouver un système fonctionnel est selon moi la priorité.
quelque soit l'origine du problème, si la rotation des logs est fonctionnel et bien configuré la partition ne sera plus saturé.

fred02840 · 16-09-2022 09:55:06

Bonjour,
Je viens de voir le nombre de contributions : merci beaucoup. Je vais les lire avec attention. Je reviens après quelques heures de silence (le temps de passer la nuit et de trouver un ordinateur qui fonctionne) : plus moyen d'accéder à quoi que ce soit. Je lance l'ordinateur, et ça coince lors du défilement indiquant l'état des éléments mis en œuvre : [FAILED] Filed to start GNOME Display Manager. Bon, sympa...
J'ai redémarré en mode recovery, ouvrir la console root. J'ai pu saisir ces deux commandes : systemctl status gdm.service (puisqu'on m'y renvoyait tout le temps). Résultat :

Loaded: loaded (/lib/systemd/system/gdm.service: static)

Active: inactive (dead)

"Dead" : ben oui...

Un petit coup de journalctl -xb (toujours sur les recommandations de la console). Et là, un flot de lignes (un petit millier), certaines en gras, d'autres en rouge, et même en rouge accentué (rouge sang, ce qui rappelle le funeste dead de tout à l'heure). J'ai pris les photos, si cela était nécessaire.

Voilà où j'en suis. Maintenant, je passe à la lecture de vos lectures, dont je vous remercie encore

fred02840 · 16-09-2022 10:03:46

@ vv222

fred02840 a écrit :

Ma première intention aurait été d'augmenter la taille de /var, ce qui n'est pas la meilleure idée qui soit… L'autre, radicale, serait de réinstaller la Debian, en prenant soin d'attribuer 10 Go à /var. Mais bon, c'est une perspective qui ne m'enchante guère…

vv222 a écrit :

Et pourquoi pas tout simplement ne pas utiliser de partition dédiée pour /var ? À quoi sert-elle dans le cas présent ?

J'ai suivi le découpage proposé lors de l'installation de la Debian. J'ai eu quelques souvenirs cuisants lors de précédentes expériences, en imposant une seule partition par exemple. Et j'ai compris progressivement l'intérêt de séparer les choses dans mon disque dur. Selon la WP (mouais, bon : je vais au plus rapide...), le répertoire /var me semble important : "Ne contient que des répertoires ou liens symboliques vers d'autres répertoires, ces derniers étant destinés à contenir des fichiers variables divers (voir les sous-répertoires pour les détails). L'objectif est de pouvoir monter le répertoire /usr en lecture seule".

Croutons · 16-09-2022 10:07:15

hello
comme te le dis raleur commence par regarder se qui peut bien être si gros dans ton dossier var

ls -lh /var

c'est surement normale que tu ne puisse plus démarrer Gnome tant que cette partition est saturé

fred02840 · 16-09-2022 10:20:11

@saitaman-san et @raleur.

Pour le volume de /var, c'est probablement plus de 7 Go, en effet (mauvaise lecture de ma part...).

Vos réponses m'inspirent quelques questions :

1. Puisque je n'ai pas accès au bureau, mais seulement à la console lors du démarrage, je suppose qu'il doit être possible de voir ce que contient le répertoire /var/log (avec plus de précisions que les résultats indiqués dans mon premier message). Je vais essayer : rien à risquer...

2. Je n'ai jamais mis le nez dans ce répertoire (/var/log). Je suppose qu'une suppression totale de son contenu n'est pas à faire, mais comment opérer une sélection pertinente et un nettoyage efficace ? Quoi que, avec LaTeX, la suppression accidentelle de fichiers .log n'a pas posé plus de problèmes que cela : en lançant et en modifiant le fichier principal (.tex), un nouveau .log était créé. Est-ce que cela fonctionne de la même façon avec le système ? A charge pour moi de surveiller ce répertoire quand je pourrai à nouveau travailler normalement avec la Debian.

Ce qui m'étonne, c'est que je ne pense pas avoir procédé à des opérations de maintenance périlleuses avant que ce problème arrive.

3. Comment retrouver un système fonctionnel ? En accédant au disque dur en s'aidant d'un DVD d'installation (j'ai dû faire cela, il y a bien longtemps) ?

Merci encore d'avoir le soin et le temps nécessaire de m'aider !

Dernière modification par fred02840 (16-09-2022 10:20:34)

fred02840 · 16-09-2022 10:23:12

@Croutons

Croutons a écrit :

hello
comme te le dis raleur commence par regarder se qui peut bien être si gros dans ton dossier var
ls -lh /var

c'est surement normale que tu ne puisse plus démarrer Gnome tant que cette partition est saturé

OK : j'essaie avec la console qui s'affiche au démarrage.
Merci beaucoup !

ubub · 16-09-2022 10:40:19

Bonjour,

possible de voir ce que contient le répertoire /var/log

essaie

 ls- lh /var/log

Croutons · 16-09-2022 10:49:52

a pas faux ubub

ls -lhS /var/log

avec l'option S se sera classé du plus gros au plus petit

Dernière modification par Croutons (16-09-2022 11:20:06)

fred02840 · 16-09-2022 10:57:10

J'ai la réponse à ma première question : comme on pouvait s'en douter, il est possible d'utiliser la console du démarrage de la même façon que le Terminal.

@croutons, voici le résultat (en root, puisque le mot de passe administrateur est requis) de

ls -lh /var

Dernière modification par fred02840 (16-09-2022 11:15:11)

ubub · 16-09-2022 11:07:15

Bonjour,

avec /var/log ça irait plus vite à la source du problème ...

ls- lhS /var/log

fred02840 · 16-09-2022 11:39:21

Très juste, @ubub...

Résultats partiels : je n'ai qu'une partie de l'écran. Comment lire l'intégralité ? Ou au moins inverser la liste (par taille croissante)...

Dernière modification par fred02840 (16-09-2022 11:41:59)

ubub · 16-09-2022 11:47:48

Si l'affichage va du plus gros au plus petit et que la recherche soit le plus gros, cela devrait être sur les premières lignes ??
sinon avec less ou more , ou tail (voir les man) je crois ce devrait être possible de n'avoir que le début/fin ou milieu ...

fred02840 · 16-09-2022 11:52:31

J'ai trouvé ici la bonne commande pour afficher les fichiers dans l'ordre de taille et les voir intégralement

ls -Ss /var/log

ubub · 16-09-2022 12:00:47

Ca serait bien d'afficher aussi la taille (en facilement lisible avec h) tant qu'à faire ...
Le problème viendrait de syslog ?

Dernière modification par ubub (16-09-2022 12:02:18)

Croutons · 16-09-2022 12:36:22

j'ai noté un écart important entre les résultat avec du et ls
alors que ls m'annonce un total 12M , du m'annonce 33M

raleur · 16-09-2022 12:54:15

Croutons a écrit :

avec l'option S se sera classé du plus gros au plus petit

Et comme il vaut mieux afficher du plus petit au plus gros au cas où ça déborde de l'écran, ajouter l'option "r".

ubub a écrit :

Le problème viendrait de syslog ?

En tout cas la rotation semble fonctionner puisque les fichiers d'anciens logs sont présents, mais il faudrait vérifier les dates pour s'en assurer.
Il y a trois fichiers qui font environ 2 Go chacun : syslog, messages et user.log. En fait ils ont des parties communes, et le problème vient manifestement de user.log, donc d'une application ou d'un composant du bureau qui génère des messages en quantité anormale. On peut regarder les 50 dernières lignes avec

tail -n 50 /var/log/user.log

Ou bien se balader dedans avec le pager mais ça risque d'être un peu lourd (q pour quitter).

pager /var/log/user.log

Cela devrait permettre d'identifier l'application responsable. Ensuite supprimer au moins un de ces trois fichiers avec "rm" pour libérer de l'espace disque. Si le problème persiste les messages reviendront dans les nouveaux logs.

Croutons a écrit :

j'ai noté un écart important entre les résultat avec du et ls
alors que ls m'annonce un total 12M , du m'annonce 33M

Si tu parles de ta machine, il vaudrait mieux ouvrir un nouveau sujet avec plus de détails et ne pas alourdir celui-ci.

Dernière modification par raleur (16-09-2022 12:56:31)

fred02840 · 16-09-2022 14:51:13

Bon, ça se précise... Et les gagnants sont (grâce à ls -lhSr /var/log : petit pense-bête personnel en passant)... [roulement de tambour...] :

user.log, messages et syslog, avec chacun la bagatelle de 1,9 Go [applaudissements bien mérités]

Je regarde ce que @raleur propose...

Dernière modification par fred02840 (16-09-2022 15:14:29)

fred02840 · 16-09-2022 15:13:47

En réponse à @raleur, j'obtiens des lignes identiques à

tail -n  /var/log/user.log

Sep 15   15:22:59   debian   pipewire[1453]  :  spa.alsa:   hw:0,3:   snd_pcm_avail   after recover: Relais brisé   (pipe)

Et il est vrai que j'avais fait ce que je pouvais, il y a quelques jours, pour essayer d'avoir du son dans un casque bluetooth (parfaitement reconnu par la Debian), bien en vain. Et que j'ai eu une interruption du son dans Firefox et Tor (mais pas dans les autres navigateurs : Falkon, Chromium), hier, avant le drame. Je leuravais ajouté une extension : Sound Control

Serait-ce le coupable ? Dans ce cas :

1. Je supprime /var/log/user.log
2. Je redémarre en mode normal
3. Si je réussis à accéder au bureau, je supprime l'extension
4. Eventuellement, je désinstalle alsa (voire pipewire, mais je vais y aller mollo...), un peu coup de clean et autoclean, et je réinstalle ensuite. J'avais installé des extensions (ou options) de pulse (pulse effects, etc.), qui ne me sont guère utiles : poubelle...

Je procède aux trois premiers points, et je vous laisse réfléchir sur ma dernière suggestion.
Merci !!

fred02840 · 16-09-2022 15:25:53

Bizarre : /var/log/user.log et /var/log/messages (ou même messages.log) n'existeraient pas... Je me suis résolu à supprimer /var/log/syslog.

J'ai réussi à redémarrer sans encombre. Me voilà sur le bureau (ouf...).

Suppression de l'extension Sound Control. Fermeture de Firefox.

Terminal :

ls -lhSr /var/log

-rw-rw-r--  1 root              utmp            1,1M 11 juil. 06:46 wtmp.1

-rw-r-----  1 root              adm             1,5M 16 sept. 16:23 daemon.log

-rw-r-----  1 root              adm             1,7M 12 sept. 12:01 user.log.1

-rw-r-----  1 root              adm             2,6M 12 sept. 12:01 kern.log.1

-rw-r-----  1 root              adm             4,1M 12 sept. 12:01 messages.1

-rw-r-----  1 root              adm              19M 12 sept. 12:01 daemon.log.1

-rw-r-----  1 root              adm              23M 12 sept. 12:01 syslog.1

De 1,9 Go, on est passé à une misérable poignée de Mo : je saurais m'en contenter et vous en être reconnaissant.

J'attends vos remarques quant à la suppression (puis réinstallation) d'Alsa, voire de Pipewire et même Pulse.
En attendant d'indiquer le problème comme [RÉSOLU], je vais surveiller très régulièrement la taille de /var/log…

Dernière modification par fred02840 (16-09-2022 15:30:05)

Debian-facile

#1 15-09-2022 14:16:48

/var quasiment plein [RÉSOLU]

#2 15-09-2022 14:56:29

Re : /var quasiment plein [RÉSOLU]

#3 15-09-2022 17:05:32

Re : /var quasiment plein [RÉSOLU]

#4 15-09-2022 17:40:01

Re : /var quasiment plein [RÉSOLU]

#5 15-09-2022 18:01:09

Re : /var quasiment plein [RÉSOLU]

#6 15-09-2022 18:28:24

Re : /var quasiment plein [RÉSOLU]

#7 15-09-2022 18:49:06

Re : /var quasiment plein [RÉSOLU]

#8 16-09-2022 09:55:06

Re : /var quasiment plein [RÉSOLU]

#9 16-09-2022 10:03:46

Re : /var quasiment plein [RÉSOLU]

#10 16-09-2022 10:07:15

Re : /var quasiment plein [RÉSOLU]

#11 16-09-2022 10:20:11

Re : /var quasiment plein [RÉSOLU]

#12 16-09-2022 10:23:12

Re : /var quasiment plein [RÉSOLU]

#13 16-09-2022 10:40:19

Re : /var quasiment plein [RÉSOLU]

#14 16-09-2022 10:49:52

Re : /var quasiment plein [RÉSOLU]

#15 16-09-2022 10:57:10

Re : /var quasiment plein [RÉSOLU]

#16 16-09-2022 11:07:15

Re : /var quasiment plein [RÉSOLU]

#17 16-09-2022 11:39:21

Re : /var quasiment plein [RÉSOLU]

#18 16-09-2022 11:47:48

Re : /var quasiment plein [RÉSOLU]

#19 16-09-2022 11:52:31

Re : /var quasiment plein [RÉSOLU]

#20 16-09-2022 12:00:47

Re : /var quasiment plein [RÉSOLU]

#21 16-09-2022 12:36:22

Re : /var quasiment plein [RÉSOLU]

#22 16-09-2022 12:54:15

Re : /var quasiment plein [RÉSOLU]

#23 16-09-2022 14:51:13

Re : /var quasiment plein [RÉSOLU]

#24 16-09-2022 15:13:47

Re : /var quasiment plein [RÉSOLU]

#25 16-09-2022 15:25:53

Re : /var quasiment plein [RÉSOLU]

Pied de page des forums