blocage au d̓©marrage /var/ plein

Le
roger.tarani
--=_54e53e3f-3b83-45fa-99ab-179ca5b288fa
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Bonjour,

J'ai tard̓© ̓  corriger un probl̓¨me de /var/ plein, apparemment caus̓© par la gourmandise excessive de docker.

Au red̓©marrage, la machine reste bloqu̓©e sur "Press Ctrl-C to cancel all filesystem checks in progress". Au bout de quelques heures et sans r̓©action ̓  Ctrl-C, il y a de s̓©rieux indices que la machine est bloqu̓©e.

Je ne sais pas comment ajouter un disque via LVM sans avoir d̓©marr̓© la machine.
Je ne sais quoi vider dans /var/ (a priori la marchandise de docker, ce qui n̓©cessite de d̓©marrer sur une clef USB)

Avant de commettre l'irr̓©parable, je pr̓©f̓¨re vous demander :
quelle est la manoeuvre ̓  privil̓©gier pour d̓©bloquer la machine ?
Merci


--=_54e53e3f-3b83-45fa-99ab-179ca5b288fa
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>Bonjour,<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>J'ai tard̓© ̓  corriger un probl̓¨me de /var/ plein, apparemment caus̓© par la gourmandise excessive de docker.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Au red̓©marrage, la machine reste bloqu̓©e sur "Press Ctrl-C to cancel all filesystem checks in progress". Au bout de quelques heures et sans r̓©action ̓  Ctrl-C, il y a de s̓©rieux indices que la machine est bloqu̓©e.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div> <!--StartFragment--><div>Je ne sais pas comment ajouter un disque via LVM sans avoir d̓©marr̓© la machine.</div><div>Je ne sais quoi vider dans /var/ (a priori la marchandise de docker, ce qui n̓©cessite de d̓©marrer sur une clef USB)<br></div><div><br data-mce-bogus="1"></div><!--EndFragment--> Avant de commettre l'irr̓©parable, je pr̓©f̓¨re vous demander : </div><div>quelle est la manoeuvre ̓  privil̓©gier pour d̓©bloquer la machine ?<br data-mce-bogus="1"></div><div>Merci<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div></div></body></html>
--=_54e53e3f-3b83-45fa-99ab-179ca5b288fa--
  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
roger.tarani
Le #26568352
--=_1f8d6887-31b0-4352-8296-b77136cffc1b
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
PS : en mode recovery, solution radicale pour vider le bazar docker :
# cd /var/lib/docker
# rm -rf *
R̓©sultat imm̓©diat : machine d̓©bloqu̓©e.
Comment ̓©viter ce genre de situation d'un syst̓¨me qui se laisse ̓©touffer jusqu'au blocage sans rien dire ? (̓  part une alerte graphique : "il reste plus que 40 Mo sur /var/, pauvre pomme !")
̓§a pourrait aussi ̓ªtre des logs ̓©normes ou autre. C'est un risque important de bloquer une machine.
Merci
De: "roger tarani" ̓€: "Liste Debian" Envoy̓©: Samedi 20 F̓©vrier 2021 01:52:04
Objet: blocage au d̓©marrage /var/ plein
Bonjour,
J'ai tard̓© ̓  corriger un probl̓¨me de /var/ plein, apparemment caus̓© par la gourmandise excessive de docker.
Au red̓©marrage, la machine reste bloqu̓©e sur "Press Ctrl-C to cancel all filesystem checks in progress". Au bout de quelques heures et sans r̓©action ̓  Ctrl-C, il y a de s̓©rieux indices que la machine est bloqu̓©e.
Je ne sais pas comment ajouter un disque via LVM sans avoir d̓©marr̓© la machine.
Je ne sais quoi vider dans /var/ (a priori la marchandise de docker, ce qui n̓©cessite de d̓©marrer sur une clef USB)
Avant de commettre l'irr̓©parable, je pr̓©f̓¨re vous demander :
quelle est la manoeuvre ̓  privil̓©gier pour d̓©bloquer la machine ?
Merci
--=_1f8d6887-31b0-4352-8296-b77136cffc1b
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>PS : en mode recovery, <!--StartFragment-->solution radicale <!--EndFragment--> pour vider le bazar docker :<br></div><div> <!--StartFragment--><pre><code># cd /var/lib/docker
# rm -rf * --=_1f8d6887-31b0-4352-8296-b77136cffc1b--
Jean-Michel OLTRA
Le #26568430
Bonjour,
Le samedi 20 février 2021, a écrit...
Comment éviter ce genre de situation d'un système qui se laisse étouffer
jusqu'au blocage sans rien dire ? (Í  part une alerte graphique : "il reste
plus que 40 Mo sur /var/, pauvre pomme !")

Tu peux utiliser un outil de surveillance, comme Icinga2, et/ou un outil
comme Ossec (créer des commandes personnalisées pour faire des `du -sh` ou
df). Ou un script perso lancé par cron, je suppose. Ou snmp ?
--
jm
laurent
Le #26568459
----=_RainLoop_609_131975809.1613852266
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Bonjour,
Pour le /var en g̓©n̓©ral des pistes on d̓©j̓  ̓©t̓© donn̓©es.
Pour docker, il y a 2 possibilit̓©s pour ̓©vit̓© qu'il remplisse le /var, en cas d'erreurs sur un conteneur il peut facilement prendre 10G en quelques heures, les logs se trouvent dans /var/lib/docker/containers/<container_id>/<container_id>-json.log, un truncate permet de faire le m̓©nage.
Pour ̓©vit̓© de docker remplisse le /var:
Option 1: Cr̓©ation d'un file system et faire un point de montage dans /var/lib/docker, aucun risque de remplir le /var
Option 2: Changer le r̓©pertoire ou se trouve les conteneurs dans /etc/docker/daemon.json
S'il existe modifier sinon le cr̓©Íƒ© avec:
{ "graph": "/monnouveauvarlibdocker" }
Un red̓©marrage de docker et il devrat se trouver dans sa nouvelle localisation, et ne pourra plus remplir le /var.
C.S.
20 f̓©vrier 2021 03:09 (mailto:) a ̓©crit:
PS : en mode recovery, solution radicale pour vider le bazar docker :
# cd /var/lib/docker # rm -rf *
R̓©sultat imm̓©diat : machine d̓©bloqu̓©e.
Comment ̓©viter ce genre de situation d'un syst̓¨me qui se laisse ̓©touffer jusqu'au blocage sans rien dire ? (̓  part une alerte graphique : "il reste plus que 40 Mo sur /var/, pauvre pomme !")
̓§a pourrait aussi ̓ªtre des logs ̓©normes ou autre. C'est un risque important de bloquer une machine.
Merci
------------------------------------
De: "roger tarani" ̓€: "Liste Debian" Envoy̓©: Samedi 20 F̓©vrier 2021 01:52:04
Objet: blocage au d̓©marrage /var/ plein
Bonjour,
J'ai tard̓© ̓  corriger un probl̓¨me de /var/ plein, apparemment caus̓© par la gourmandise excessive de docker.
Au red̓©marrage, la machine reste bloqu̓©e sur "Press Ctrl-C to cancel all filesystem checks in progress". Au bout de quelques heures et sans r̓©action ̓  Ctrl-C, il y a de s̓©rieux indices que la machine est bloqu̓©e.
Je ne sais pas comment ajouter un disque via LVM sans avoir d̓©marr̓© la machine.
Je ne sais quoi vider dans /var/ (a priori la marchandise de docker, ce qui n̓©cessite de d̓©marrer sur une clef USB)
Avant de commettre l'irr̓©parable, je pr̓©f̓¨re vous demander :
quelle est la manoeuvre ̓  privil̓©gier pour d̓©bloquer la machine ?
Merci
----=_RainLoop_609_131975809.1613852266
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
----=_RainLoop_609_131975809.1613852266--
cs_debusr_fr
Le #26568460
----=_RainLoop_457_381874753.1613853563
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Bonjour,
Pour le /var en g̓©n̓©ral des pistes on d̓©j̓  ̓©t̓© donn̓©es.
Pour docker, il y a 2 possibilit̓©s pour ̓©vit̓© qu'il remplisse le /var, en cas d'erreurs sur un conteneur il peut facilement prendre 10G en quelques heures, les logs se trouvent dans /var/lib/docker/containers/<container_id>/<container_id>-json.log, un truncate permet de faire le m̓©nage.
Pour ̓©vit̓© de docker remplisse le /var:
Option 1: Cr̓©ation d'un file system et faire un point de montage dans /var/lib/docker, aucun risque de remplir le /var
Option 2: Changer le r̓©pertoire ou se trouve les conteneurs dans /etc/docker/daemon.json
S'il existe modifier sinon le cr̓©Íƒ© avec:
{ "graph": "/monnouveauvarlibdocker" }
Un red̓©marrage de docker et il devrat se trouver dans sa nouvelle localisation, et ne pourra plus remplir le /var.
C.S.
20 f̓©vrier 2021 03:09 (mailto:) a ̓©crit:
PS : en mode recovery, solution radicale pour vider le bazar docker :
# cd /var/lib/docker # rm -rf *
R̓©sultat imm̓©diat : machine d̓©bloqu̓©e.
Comment ̓©viter ce genre de situation d'un syst̓¨me qui se laisse ̓©touffer jusqu'au blocage sans rien dire ? (̓  part une alerte graphique : "il reste plus que 40 Mo sur /var/, pauvre pomme !")
̓§a pourrait aussi ̓ªtre des logs ̓©normes ou autre. C'est un risque important de bloquer une machine.
Merci
------------------------------------
De: "roger tarani" ̓€: "Liste Debian" Envoy̓©: Samedi 20 F̓©vrier 2021 01:52:04
Objet: blocage au d̓©marrage /var/ plein
Bonjour,
J'ai tard̓© ̓  corriger un probl̓¨me de /var/ plein, apparemment caus̓© par la gourmandise excessive de docker.
Au red̓©marrage, la machine reste bloqu̓©e sur "Press Ctrl-C to cancel all filesystem checks in progress". Au bout de quelques heures et sans r̓©action ̓  Ctrl-C, il y a de s̓©rieux indices que la machine est bloqu̓©e.
Je ne sais pas comment ajouter un disque via LVM sans avoir d̓©marr̓© la machine.
Je ne sais quoi vider dans /var/ (a priori la marchandise de docker, ce qui n̓©cessite de d̓©marrer sur une clef USB)
Avant de commettre l'irr̓©parable, je pr̓©f̓¨re vous demander :
quelle est la manoeuvre ̓  privil̓©gier pour d̓©bloquer la machine ?
Merci
----=_RainLoop_457_381874753.1613853563
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
----=_RainLoop_457_381874753.1613853563--
roger.tarani
Le #26568527
--=_06c948b8-a288-409e-bc24-0f77a7062e27
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Merci ̓  tous pour vos pistes instructives.
Je d̓©couvre qu'il se passe des choses ̓©tonnantes en mati̓¨re de logs dans /var/log/ :
/var/log$ lla -h | grep G
total 7.7G
-rw-r----- 1 root adm 2.0G Feb 20 19:16 kern.log.1
-rw-r----- 1 root adm 1.5G Feb 21 00:00 messages.1
-rw-r----- 1 root adm 1.9G Feb 21 00:00 syslog.1
̓§a me semble ̓©norme.
1/ Est-ce que je peux supprimer ces fichiers ? (plut̓´t oui)
2/ Quelle est la mani̓¨re la plus propre d'̓©liminer/d'emp̓ªcher automatiquement des journaux aussi volumineux ? (je peux utiliser crontab et tester/̓©liminer fichier plus gros que..)
Merci
Bonne fin de we
De: "cs debusr fr" ̓€: "Liste Debian" Envoy̓©: Samedi 20 F̓©vrier 2021 21:39:23
Objet: Re: blocage au d̓©marrage /var/ plein
Bonjour,
Pour le /var en g̓©n̓©ral des pistes on d̓©j̓  ̓©t̓© donn̓©es.
Pour docker, il y a 2 possibilit̓©s pour ̓©vit̓© qu'il remplisse le /var, en cas d'erreurs sur un conteneur il peut facilement prendre 10G en quelques heures, les logs se trouvent dans /var/lib/docker/containers/<container_id>/<container_id>-json.log, un truncate permet de faire le m̓©nage.
Pour ̓©vit̓© de docker remplisse le /var:
Option 1: Cr̓©ation d'un file system et faire un point de montage dans /var/lib/docker, aucun risque de remplir le /var
Option 2: Changer le r̓©pertoire ou se trouve les conteneurs dans /etc/docker/daemon.json
S'il existe modifier sinon le cr̓©Íƒ© avec:
{ "graph": "/monnouveauvarlibdocker" }
Un red̓©marrage de docker et il devrat se trouver dans sa nouvelle localisation, et ne pourra plus remplir le /var.
C.S.
20 f̓©vrier 2021 03:09 [ mailto: | ] a ̓©crit:

PS : en mode recovery, solution radicale pour vider le bazar docker :
# cd /var/lib/docker # rm -rf *
R̓©sultat imm̓©diat : machine d̓©bloqu̓©e.
Comment ̓©viter ce genre de situation d'un syst̓¨me qui se laisse ̓©touffer jusqu'au blocage sans rien dire ? (̓  part une alerte graphique : "il reste plus que 40 Mo sur /var/, pauvre pomme !")
̓§a pourrait aussi ̓ªtre des logs ̓©normes ou autre. C'est un risque important de bloquer une machine.
Merci
De: "roger tarani" ̓€: "Liste Debian" Envoy̓©: Samedi 20 F̓©vrier 2021 01:52:04
Objet: blocage au d̓©marrage /var/ plein
Bonjour,
J'ai tard̓© ̓  corriger un probl̓¨me de /var/ plein, apparemment caus̓© par la gourmandise excessive de docker.
Au red̓©marrage, la machine reste bloqu̓©e sur "Press Ctrl-C to cancel all filesystem checks in progress". Au bout de quelques heures et sans r̓©action ̓  Ctrl-C, il y a de s̓©rieux indices que la machine est bloqu̓©e.
Je ne sais pas comment ajouter un disque via LVM sans avoir d̓©marr̓© la machine.
Je ne sais quoi vider dans /var/ (a priori la marchandise de docker, ce qui n̓©cessite de d̓©marrer sur une clef USB)
Avant de commettre l'irr̓©parable, je pr̓©f̓¨re vous demander :
quelle est la manoeuvre ̓  privil̓©gier pour d̓©bloquer la machine ?
Merci


--=_06c948b8-a288-409e-bc24-0f77a7062e27
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
--=_06c948b8-a288-409e-bc24-0f77a7062e27--
cs_debusr_fr
Le #26568528
21 février 2021 22:10 a écrit:
Je découvre qu'il se passe des choses étonnantes en matière de logs dans /var/log/ :
/var/log$ lla -h | grep G
total 7.7G
-rw-r----- 1 root adm 2.0G Feb 20 19:16 kern.log.1
-rw-r----- 1 root adm 1.5G Feb 21 00:00 messages.1
-rw-r----- 1 root adm 1.9G Feb 21 00:00 syslog.1
ça me semble énorme.

Oui et non, ça dépend de se qui se passe sur la machine.
1/ Est-ce que je peux supprimer ces fichiers ? (plutÍ´t oui)

1. Normalement quand il y a un grand nombre de log, c'est soit les niveaux de log est trop élevé,
(mode debug activé) soit qu'il y a y un problème quelques part qui génère les logs, soit logrotate
qui n'est pas activé (pas le cas ici). Dans tous les cas la suppression des fichiers en question ne
réglera pas le problème et les logs grossiront de nouveau.
2/ Quelle est la manière la plus propre d'éliminer/d'empêcher automatiquement des journaux aussi
volumineux ? (je peux utiliser crontab et tester/éliminer fichier plus gros que..)

2. Regarder les logs pour déterminer l'application ou le service qui génère autant de volume, et
corriger le problème. ensuite il est possible de paramétrer logrotate pour faire un gzip Í  la
première rotation (ensuite utiliser les commandes zless, zcat, zgrep et z* pour exploiter les
fichiers gzip)
Sinon, tous les outils existent pour gérer les logs sans avoir recourt Í  des scripts ou autre, ne pas oublié que l'objectif des journaux :) si on les élimines car ils sont trop gros il y a risque de passer Í  coté de quelque chose.
Merci
Bonne fin de we
Stephane Ascoet
Le #26568726
Le 22/02/2021 Í  10:38, Pierre Malard a écrit :
Salut,
J’aurais tendance Í  conseiller ceci :
1) sauvegarder le contenu de /var/log sur un autre support
2) Effacer les logs présent par exemple avec un :
# find /var/log -type f ( -iname "*.[0-9].log" -o -iname "*.[0-9].log.gz" -o -iname "*.[0-9][0-9].log" -o -iname "*.[0-9][0-9].log.gz" -o -iname "*.[0-9]" -o -iname "*.[0-9].gz" -o -iname "*.[0-9][0-9]" -o -iname "*.[0-9][0-9].gz" ) -exec /bin/rm -f {} ;
Ce qui efface tout fichier log traité par logrotate. Il y a certainement un regex fou qui fait ça en un test. LÍ , au moins, c’est lisible).

Bonjour, quelque chose comme(pas teste a fond, mais la tienne me semble
supprimer trop de choses): find /var/log -regextype posix-extended
-regex '.*.[[:digit:]]+.*' -print | egrep -v 'log$' | xargs mv -t
/media/fujitsugigamo
Et pour le probleme de fond, reponse facile qui correspondrait a ce que
je fais depuis toujours: dans ce cas, j'abandonnerai l'idee de mettre en
mode S3 de veille...
--
Cordialement, Stephane Ascoet
Stephane Ascoet
Le #26568728
Le 22/02/2021 Í  10:22, Erwann Le Bras a écrit :
3. un "barbu" appréciera un petit script en crontab "/hourly/" qui
envoie un mail ou un sms en cas d'espace disque insuffisant
(c-Í -d Í  80 ou 90% de l'espace occupé) ; un curieux
expérimentateur ira regarder du cÍ´té de Nagios

J'ai fait ca sur mon GOBook, lance toutes les minutes, plus pour pallier
les mauvaises manipulations de l'utilisateur(moi-meme) comme mettre trop
de gros trucs dans /tmp que pour les problemes de journaux. J'aimerais
avoir le temps, les competences et la motivation pour rajouter d'autres
tests, comme celui d'une batterie presque vide, etc.
Par contre, pas de courriel ni de SMS, selon la presence ou pas d'un
serveur X ca fait plutot un truc style wall et/ou un xmessage
--
Cordialement, Stephane Ascoet
roger.tarani
Le #26568816
A défaut d'avoir corrigé le problème de la carte PCI en sortie de veille, je l'ai déconnectée : plus de problèmes de logs !...
Merci pour les regex.
Le mode S3 (suspend to RAM ) et le mode S4 (suspend to disk) : en debian, on oublie ou on peut s'en servir ? et alors comment ?

----- Mail original -----
De: "Stephane Ascoet" À: "Liste Debian" Envoyé: Mercredi 24 Février 2021 14:27:39
Objet: Re: blocage au démarrage /var/ plein
Le 22/02/2021 Í  10:38, Pierre Malard a écrit :
Salut,
J’aurais tendance Í  conseiller ceci :
1) sauvegarder le contenu de /var/log sur un autre support
2) Effacer les logs présent par exemple avec un :
# find /var/log -type f ( -iname "*.[0-9].log" -o -iname "*.[0-9].log.gz" -o -iname "*.[0-9][0-9].log" -o -iname "*.[0-9][0-9].log.gz" -o -iname "*.[0-9]" -o -iname "*.[0-9].gz" -o -iname "*.[0-9][0-9]" -o -iname "*.[0-9][0-9].gz" ) -exec /bin/rm -f {} ;
Ce qui efface tout fichier log traité par logrotate. Il y a certainement un regex fou qui fait ça en un test. LÍ , au moins, c’est lisible).

Bonjour, quelque chose comme(pas teste a fond, mais la tienne me semble
supprimer trop de choses): find /var/log -regextype posix-extended
-regex '.*.[[:digit:]]+.*' -print | egrep -v 'log$' | xargs mv -t
/media/fujitsugigamo
Et pour le probleme de fond, reponse facile qui correspondrait a ce que
je fais depuis toujours: dans ce cas, j'abandonnerai l'idee de mettre en
mode S3 de veille...
--
Cordialement, Stephane Ascoet
Stephane Ascoet
Le #26568841
Le 25/02/2021 Í  01:05, a écrit :
Le mode S3 (suspend to RAM ) et le mode S4 (suspend to disk) : en debian, on oublie ou on peut s'en servir ? et alors comment ?

Bonjour, il me semblait que c'etait bien du S3 que tu faisais... Le S4,
on en a parle plein de fois ces dernieres annees sur la liste,
pesonnellement j'ai toujours dit que je n'aimais pas...
--
Cordialement, Stephane Ascoet
Poster une réponse
Anonyme