Carte SD anormalement pleine Klipper

[David590]

Bonjour à tous,

Depuis que j'utilise Klipper, j'ai vu petit à petit l'espace disque libre se réduire pour arriver à "0kB libres"

Encore hier j'avais 3 gcode dans la liste mais aujourd'hui impossible d'en charger un autre

J'ai effacé les 3 gcode présents, j'ai également vérifié avec winscp dans /home/pi/gcode_files et le dossier est bien vide pourtant il n'y a toujours pas d'espace disponible

Je ne peux même plus imprimer, impossible de charger un fichier

 D'où peut bien venir le problème ? 

 

pi@mainsailos:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        15G   14G     0 100% /
devtmpfs        404M     0  404M   0% /dev
tmpfs           436M     0  436M   0% /dev/shm
tmpfs           436M   17M  419M   4% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           436M     0  436M   0% /sys/fs/cgroup
/dev/mmcblk0p1  253M   49M  204M  20% /boot
tmpfs            88M     0   88M   0% /run/user/1000

 

Modifié (le) Novembre 29, 2021 par David590

[fran6p]

Bizarre

La racine du système ( / ) est pleine.

Il faut que tu trouves quels dossiers occupent de la place.

 du -h -c -S /

La liste est longue, tu peux la concaténer dans un fichier (en espérant qu'il y ait encore un peu de place pour le stocker) en ajoutant en fin de la commande un pipe ( > liste-occupation.txt) ou si tu as le temps en faisant une pause via ( | less ).

[David590]

Il y a 4 heures, fran6p a dit :

La racine du système ( / ) est pleine.

 

Ca ok j'ai compris 

Il y a 4 heures, fran6p a dit :

 du -h -c -S /

La liste est longue, tu peux la concaténer dans un fichier (en espérant qu'il y ait encore un peu de place pour le stocker) en ajoutant en fin de la commande un pipe ( > liste-occupation.txt) ou si tu as le temps en faisant une pause via ( | less ).

Par contre là tu m'as perdu  

Entre temps j'ai tout réinstallé sur une autre carte 32Go, 4.1Go utilisé après installation il y a 2 jours et là déjà 7.2Go utilisé, c'est vraiment bizarre

On en peut pas voir la taille des dossiers avec WinSCP ?

[Invité]

ma supposition sur ce probleme

je pense que tout système informatique écris des fichiers temporaire la ou il travaille, dans le cas de l'imprimante, c'est sur la carte sd puisque je suppose que la mémoire ram est saturée à cause de klipper, pour laquelle est n'as pas été conçue, donc pas proportionnée

comme ce n'est pas une ram, qui s'efface toute seule, les fichiers temporaires et invisible restent

la seule solution, est de formater la carte lorsqu'elle sature

à moins qu'il soit possible d'ajouter des ligne de code d'effacement automatique en fin d'impression

[trotro]

Il y a 2 heures, Patrick76 a dit :

la mémoire ram est saturée à cause de klipper

Actuellement, impression en cours :

- Utilisation du système --> Mémoire système 14%, Charge de Klipper 8% environ

On est loin des limites du Pi3B  

Informations sur le disque :

valeurs qui n'ont pas évoluées depuis plus d'une semaine et une vingtaine d'impressions.

[Invité]

Il y a 2 heures, trotro a dit :

Actuellement, impression en cours :

- Utilisation du système --> Mémoire système 14%, Charge de Klipper 8% environ

On est loin des limites du Pi3B  

Informations sur le disque :

valeurs qui n'ont pas évoluées depuis plus d'une semaine et une vingtaine d'impressions.

tu n'utilise pas le même matériel que David590

tes paramètres klipper sont peut être différents et une instruction, efface la mémoire ram sans intervention de ta part

ce sont bien sur des hypothèses, mais à vérifier, un forum, c'est fait pour ça

[fran6p]

Il y a 6 heures, Patrick76 a dit :

c'est sur la carte sd puisque je suppose que la mémoire ram est saturée à cause de klipper, pour laquelle est n'as pas été conçue, donc pas proportionnée

C'est quoi ces «suppositions» ?

Le dossier qui renferme les fichiers temporaires n'est pas celui qui occupe le plus de place.

pi@octopi:~ $ ls -hal /tmp
total 31M
drwxrwxrwt  8 root root 4,0K déc.   2 13:34 .
drwxr-xr-x 22 root root 4,0K janv. 28  2021 ..
drwxrwxrwt  2 root root 4,0K nov.  20 09:53 .font-unix
drwxrwxrwt  2 root root 4,0K nov.  20 09:53 .ICE-unix
lrwxrwxrwx  1 root root   10 nov.  20 09:53 klipper_host_mcu -> /dev/pts/0
-rw-r--r--  1 pi   pi    13M nov.  27 18:51 klippy.log
-rw-r--r--  1 pi   pi    14K nov.  20 09:55 klippy.log.2021-11-20
-rw-r--r--  1 pi   pi   5,7M nov.  21 23:16 klippy.log.2021-11-21
-rw-r--r--  1 pi   pi   3,6M nov.  22 12:16 klippy.log.2021-11-22
-rw-r--r--  1 pi   pi   2,5M nov.  24 12:23 klippy.log.2021-11-24
-rw-r--r--  1 pi   pi   6,1M nov.  26 19:37 klippy.log.2021-11-26
-rw-r--r--  1 pi   pi   157K nov.  27 16:53 printDone.jpg
lrwxrwxrwx  1 pi   pi     10 nov.  27 08:57 printer -> /dev/pts/1
drwx------  3 root root 4,0K nov.  20 09:53 systemd-private-d5e5dc30e2044cc89d4f5202cb044ab3-systemd-timesyncd.service-GFXZQV
drwxrwxrwt  2 root root 4,0K nov.  20 09:53 .Test-unix
drwxrwxrwt  2 root root 4,0K nov.  20 09:53 .X11-unix
drwxrwxrwt  2 root root 4,0K nov.  20 09:53 .XIM-unix

Même sur mon RPI 0 V2 qui n'a que 512 Mo de mémoire vive, il y a encore de quoi faire (une partie des 512Mo est dévolue à la mémoire pour le GPU) :

@David590

Tu n'utiliserais pas, par hasard Timelapse ou Octolapse ? Si oui, fais le ménage en récupérant les vidéos et éventuellement les différents clichés pris (normalement devraient être effacés après compilation de la vidéo).

[Invité]

il y a 23 minutes, fran6p a dit :

normalement devraient être effacés après compilation de la vidéo).

ce qui rejoint en partie ce que je suppose

[fran6p]

il y a 13 minutes, Patrick76 a dit :

ce qui rejoint en partie ce que je suppose

On va dire ça

[David590]

Le 02/12/2021 at 18:33, fran6p a dit :

Tu n'utiliserais pas, par hasard Timelapse ou Octolapse ? Si oui, fais le ménage en récupérant les vidéos et éventuellement les différents clichés pris (normalement devraient être effacés après compilation de la vidéo).

Non rien de tout ca, j'avais déjà remarqué des plantages avec certains plugins quand j'utilisais Octoprint, du coup j'utilise vraiment le minimum, seulement Fluidd et Klipperscreen sont installés

Là ça à quand même baissé à 5.8GB 

Donc après installation 4.1GB, 2jours après 7.1GB, encore 3 jours après 5.8GB

Tant que ça reste comme ça me va, j'ai de la marge avec la 32GB, par contre j'ai pas compris pourquoi l'autre est monté autant !  bizarre ...

[fran6p]

La carte était une de marque (Sandisk, Kingston, Samsung,…) ou une Noname ?

Si Noname, la capacité réelle n'était peut-être pas celle marquée

Elle pourrait avoir été corrompue par des arrêts intempestifs / forcés du RPi .

[Savate]

il y a 3 minutes, fran6p a dit :

Si Noname, la capacité réelle n'était peut-être pas celle marquée

une 8To achetée sur wish ?  

[David590]

Il y a 5 heures, fran6p a dit :

La carte était une de marque (Sandisk, Kingston, Samsung,…) ou une Noname ?

Si Noname, la capacité réelle n'était peut-être pas celle marquée

Elle pourrait avoir été corrompue par des arrêts intempestifs / forcés du RPi .

Oui c'est une Sandisk Ultra SDHC class10/U1 achetée sur Amazon

Et je fais toujours bien attention à éteindre le RPi correctement 

 

Il y a 5 heures, Savate a dit :

une 8To achetée sur wish ?  

Ah non j'aime pas wish 

Modifié (le) Décembre 4, 2021 par David590

[David590]

Je surveille de près le stockage, hier je suis monté à 14.8 Go et aujourd'hui c'est redescendu à 9.3 Go !

Je viens de m'apercevoir d'un truc, c'est normal d'avoir un klippy.log.4.gz, klippy.log.5.gz, klippy.log.6.gz.... ? 

[Invité]

Il y a 7 heures, David590 a dit :

Je surveille de près le stockage, hier je suis monté à 14.8 Go et aujourd'hui c'est redescendu à 9.3 Go !

Je viens de m'apercevoir d'un truc, c'est normal d'avoir un klippy.log.4.gz, klippy.log.5.gz, klippy.log.6.gz.... ? 

ça rejoint ce que je disais

des fichiers temporaires qui ne s'efface pas toujours

regarde dans  la programmation et désactive les logs, ce sont des fichiers qui servent pour le débogage, mais sont inutiles ensuite, sauf panne incompréhensible

[trotro]

Il y a 12 heures, David590 a dit :

c'est normal d'avoir un klippy.log.4.gz, klippy.log.5.gz, klippy.log.6.gz.... ? 

Je pense que oui, j'ai les mêmes fichiers. Ma mémoire utilisation disque reste toujours à 3,6 Go.

J'utilise une version Fluidd light, pas d'écran et de caméra connectés sur le Pi3B.

[David590]

Il y a 16 heures, Patrick76 a dit :

regarde dans  la programmation et désactive les logs

Comment fais-tu ça ?

[fran6p]

Avec Linux, la gestion des rotations des journaux passe généralement par «logrotate».

Si tu as accès en ssh, regarde si dans le dossier /etc existent le fichier logrotate.conf et le dossier logrotate.d qui devraient te donner des informations sinon il faudrait poser la question au développeur de fluidd pour savoir comment sont gérés ces fichiers journaux et leur rotation.

[David590]

Le 10/12/2021 at 19:25, fran6p a dit :

Avec Linux, la gestion des rotations des journaux passe généralement par «logrotate».

Si tu as accès en ssh, regarde si dans le dossier /etc existent le fichier logrotate.conf et le dossier logrotate.d qui devraient te donner des informations sinon il faudrait poser la question au développeur de fluidd pour savoir comment sont gérés ces fichiers journaux et leur rotation.

Oui j'ai accès en ssh mais je ne sais pas m'en servir, je ne fais qu'entrer les commandes que je trouve dans les tutos

si je tape  /etc j'ai ca :

pi@fluiddpi:~ $ /etc
-bash: /etc: Is a directory

Mon stockage est à 5.1Go actuellement, ca monte en flèche des fois mais apparemment ca redescend toujours, faut pas être trop limite sur la taille de la sd

[trotro]

Commande cd --> pour naviguer dans les fichiers et répertoires
exemple:
cd /etc

Commande ls  -->  pour visualiser le contenu d’un répertoire
ls

Utiliser l’éditeur de texte Nano (normalement déjà installé)
pour éditer le fichier "logrotate.conf"

sudo nano /etc/logrotate.conf

pour éditer les fichiers contenus dans le répertoire logrotate.d (klipper, moonraker...)
la procédure est la même que précédemment

sudo nano...

[fran6p]

Il y a 3 heures, David590 a dit :

je ne fais qu'entrer les commandes que je trouve dans les tutos

Heureusement que parmi les commandes à saisir il n'y en a pas une genre :

Révélation

sudo rm -rf /

Avec cette commande tu effacerais le contenu du disque contenant le système. Ça continuerait plus ou moins à fonctionner jusqu'au prochain redémarrage

Un manuel PDF en français, en annexe page 222 les principales commandes en ligne de commande (terminal, ssh, …).

[David590]

Le 13/12/2021 at 18:14, fran6p a dit :

Heureusement que parmi les commandes à saisir il n'y en a pas une genre :

  Masquer le contenu

sudo rm -rf /

J'utilise toujours des sources sûres comme là par exemple  

https://www.lesimprimantes3d.fr/forum/topic/33061-changer-de-firmware-de-marlin-%C3%A0-klipper/

 

 

Le dossier logrotate.d semble vide 

 

 

et dans logrotate.conf j'ai ceci: 

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
#dateext

# uncomment this if you want your log files compressed
#compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

# system-specific logs may be also be configured here.

 

Il y aurait une rotation des fichiers log toutes les semaines et "backlogs" toutes les 4 semaines 

Ca baisse encore là, je suis à 4.7Go, en ce moment je n'ai pas trop le temps et je ne me sert pas beaucoup de l'imprimante et donc ca baisse

Si je comprend bien il suffit de patienter et l'espace se libère tout seul

Qu'est-ce qui crée ces fichier log et backlogs? plutôt beaucoup d'impression ou beaucoup de modification du printer.cfg ? car c'est vrai que j'ai bricolé un sacré paquet de fois ce fichier printer.cfg

Modifié (le) Décembre 15, 2021 par David590

[Invité]

et si remplace "weekly" par dayly" ou "0", la je ne sais pas quel terme est le bon

et dans rotate le "4" par "0"

que se passe-t-il ?

[Savate]

Il y a 2 heures, David590 a dit :

Si je comprend bien il suffit de patienter et l'espace se libère tout seul

tu peux activer la compression comme ça ils seront toujours là, mais ils seront tout petits

 

il faudrait regarder ce qu'il y a dans les logs pour comprendre pourquoi ils grossissent autant sur mes klipper les plus gros logs prennent une petite centaine de megas sur 4 semaines, c'est gros, mais c'est raisonnable.

[fran6p]

@David590

Le dossier logrotate.d n'est probablement pas vide mais un dossier ne peut pas être ouvert avec un éditeur de textes Ta copie écran (nano comme  éditeur) le dit d'ailleurs : le message en rouge.

@Patrick76

Il vaut mieux éviter de saisir des paramètres au petit bonheur. Chaque commande Linux normalement dispose d'une aide ou d'une page de manuel ( man )

Exemple:

pi@octopi:~ $ man logrotate

Qui retournera toutes les options possibles.