Re: blocage au démarrage /var/ plein
Oui, je faisais du S3 (suspend to RAM). Je parlais juste du S3 et du S4 (suspend to disk) de manière générale. Surtout pour récapituler les cas auxquels il faut faire gaffe. Si on faisais un sondage, je ne suis pas sûr que tout le mond connaisse les pièges de ces deux modes d'hibernation. - Mail original - De: "Stephane Ascoet" À: "Liste Debian" Envoyé: Jeudi 25 Février 2021 10:18:25 Objet: Re: blocage au démarrage /var/ plein Le 25/02/2021 à 01:05, roger.tar...@free.fr 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
Re: blocage au démarrage /var/ plein
Le 25/02/2021 à 01:05, roger.tar...@free.fr 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
Re: blocage au démarrage /var/ plein
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
Re: blocage au démarrage /var/ plein
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
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
Re: blocage au démarrage /var/ plein
: Card removed?
comedi comedi0: ni_tio_handle_interrupt: Gi_Gate_Error detected.
comedi comedi0: ni_tio_handle_interrupt: Gi_Gate_Error detected.
comedi comedi0: Card removed?
comedi comedi0: ni_tio_handle_interrupt: Gi_Gate_Error detected.
comedi comedi0: ni_tio_handle_interrupt: Gi_Gate_Error detected.
- Mail original -
De: "Bernard Schoenacker"
À: "Pierre Malard"
Cc: "Liste Debian"
Envoyé: Lundi 22 Février 2021 13:24:51
Objet: Re: blocage au démarrage /var/ plein
- Mail original -
> De: "Pierre Malard"
> À: "debian-user-french@lists.debian.org French"
>
> Envoyé: Lundi 22 Février 2021 10:38:53
> Objet: Re: blocage au démarrage /var/ plein
> 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 :
> --
> Pierre Malard
> Responsable architectures système GeoSUD
> IRD - UMR Espace-Dev - UMS CPST
> Maison de la Télédétection
> 500 rue Jean-François Breton
> 34093 Montpellier Cx 5
> France
Bonjour,
voici une solution :
find /var/log/ -type f -mtime +1 -name "*.gz" -exec rm -rf {} \;
pour le répertoire journal, voici mon idée de base :
find /var/log/journal/*/ -type f -atime +1 -exec rm -rf {} \;
pour le /tmp :
find /tmp/ -type f -atime +1 -exec rm -rf {} \;
Merci pour votre aimable attention
Bien à vous
Bernard
Re: blocage au démarrage /var/ plein
- Mail original -
> De: "Pierre Malard"
> À: "debian-user-french@lists.debian.org French"
>
> Envoyé: Lundi 22 Février 2021 10:38:53
> Objet: Re: blocage au démarrage /var/ plein
> 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 :
> --
> Pierre Malard
> Responsable architectures système GeoSUD
> IRD - UMR Espace-Dev - UMS CPST
> Maison de la Télédétection
> 500 rue Jean-François Breton
> 34093 Montpellier Cx 5
> France
Bonjour,
voici une solution :
find /var/log/ -type f -mtime +1 -name "*.gz" -exec rm -rf {} \;
pour le répertoire journal, voici mon idée de base :
find /var/log/journal/*/ -type f -atime +1 -exec rm -rf {} \;
pour le /tmp :
find /tmp/ -type f -atime +1 -exec rm -rf {} \;
Merci pour votre aimable attention
Bien à vous
Bernard
Re: blocage au démarrage /var/ plein
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).
Suivit d’un :
# find /var/log -type f -exec /bin/cp /dev/null {} \;
qui vide tout fichier log restant
3) Visiter les /tmp pour voir si ils n’ont pas également de gros fichiers
4) Analyser les logs sauvegardés pour voir ce qui a provoquer cet embonpoint…
Si c’est à cause d’un niveau de log trop élevé dans une application (p.e. un
niveau « debug » dans Apache ou Samba). Rabaisser le niveau en « info » ou «
error »
Si c’est à cause d’un problème avec un paquet, le résoudre.
5) Si cela a dégagé suffisamment de place, redémarrer le serveur
6) Surveiller le petit comme le lait sur le feu…
> Le 22 févr. 2021 à 10:22, Erwann Le Bras a écrit
> :
>
>
> Le 21/02/2021 à 22:10, roger.tar...@free.fr a
> écrit :
>> 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 adm2.0G Feb 20 19:16 kern.log.1
>> -rw-r- 1 root adm1.5G Feb 21 00:00 messages.1
>> -rw-r- 1 root adm1.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..)
>>
>>
> bonjour
>
> à supprimer, oui, et tous les fichiers compressés au même niveau
> en prévention :
> Regarder qui loggue quoi et voir pour abaisser le niveau de log si besoin :
> si ça se trouve un truc loggue inopportunément en mode "debug" ; un vrai pb
> peut y être remonté et rabaché souvent
> paramétrer logrotate pour faire tourner et compresser ces fichier plus
> rapidement
> 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
>
> amitiés,
>
> --
> Erwann Le Bras
>
--
Pierre Malard
Responsable architectures système GeoSUD
IRD - UMR Espace-Dev - UMS CPST
Maison de la Télédétection
500 rue Jean-François Breton
34093 Montpellier Cx 5
France
« SPAM : Spieced Pork and Meat »
Pierre Dac (Londres, 1944)
Extrait de « Pierre DAC parle au Français » sur Radio Londres, le 24 mars 1944,
dans Drôle de guerre, éditions Omnibus (2008), pages 93 à 96.
(https://www.epi.asso.fr/revue/articles/a1602d.htm)
|\ _,,,---,,_
/,`.-'`'-. ;-;;,_
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_) πr
perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\
( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_):
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--
signature.asc
Description: Message signed with OpenPGP
Re: blocage au démarrage /var/ plein
Le 21/02/2021 à 22:10, roger.tar...@free.fr a écrit : 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..) bonjour 1. à supprimer, oui, et tous les fichiers compressés au même niveau 2. en prévention : 1. Regarder qui loggue quoi et voir pour abaisser le niveau de log si besoin : si ça se trouve un truc loggue inopportunément en mode "debug" ; un vrai pb peut y être remonté et rabaché souvent 2. paramétrer /logrotate/ pour faire tourner et compresser ces fichier plus rapidement 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 3. amitiés, -- Erwann Le Bras
Re: blocage au démarrage /var/ plein
21 février 2021 22:10 roger.tar...@free.fr 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
Re: blocage au démarrage /var/ plein
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//-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:roger.tar...@free.fr | roger.tar...@free.fr ] 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" < [ mailto:roger.tar...@free.fr | roger.tar...@free.fr ] >
À: "Liste Debian" < [ mailto:debian-user-french@lists.debian.org |
debian-user-french@lists.debian.org ] >
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
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//-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 roger.tar...@free.fr (mailto:roger.tar...@free.fr) 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" mailto:roger.tar...@free.fr)>
À: "Liste Debian" mailto:debian-user-french@lists.debian.org)>
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
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//-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 roger.tar...@free.fr (mailto:roger.tar...@free.fr) 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" mailto:roger.tar...@free.fr)>
À: "Liste Debian" mailto:debian-user-french@lists.debian.org)>
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
Re: blocage au démarrage /var/ plein
Bonjour, Le samedi 20 février 2021, roger.tar...@free.fr 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
Fwd: blocage au démarrage /var/ plein
- Mail transféré - > De: "Bernard Schoenacker" > À: "roger tarani" > Envoyé: Samedi 20 Février 2021 06:18:02 > Objet: Re: blocage au démarrage /var/ plein > > Bonjour Roger, > > avant de supprimer sans réfléchir, je te conseille > d'employer la commande df -h / /var > > Ensuite, il faut faire le ménage en nettoyant > le cache des paquets installés (root) > > rm -rf /var/cache/apt/archives/*.deb > > refaire une vérification pour obtenir > la valeur de l'espace occuppé : > > df -h / /var > > paquet intéressant à installer :deborphan > > sudo apt install -y deborphan > > sudo apt purge -y $(deborphan |xargs) > > pour les journaux (log) il suffit de lancer > la commande via find et de supprimer les anciennes > archives ... > > > merci > @+ > Bernard
Re: blocage au démarrage /var/ plein
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
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
