arcodange-org/tools
1
0
Fork 0
Code Issues 10 Pull Requests Actions Packages Projects Releases Wiki Activity

Incident — MinIO de prod en CrashLoopBackOff depuis au moins 26 h (« drive is faulty », pi2) : aucune vidéo ne se sauvegarde ni ne se relit #49

New Issue
Closed
opened 2026-09-15 09:38:36 +02:00 by arcodange · 5 comments
arcodange commented 2026-09-15 09:38:36 +02:00
Owner
Copy Link
Copy Source

Constat (2026-09-15, 9 h 35, lecture seule, contexte kubectl default)

  • Pod tools/minio-56975fd45-s8j8k sur pi2 : 0/1 CrashLoopBackOff, 313 redémarrages en 26 h.
  • Image quay.io/minio/minio:RELEASE.2024-12-18T13-15-44Z, PVC minio 50 Gi Longhorn (pvc-ebb2605f-0597-43ef-a3d0-6b3c7c8fe3b2), Bound.
  • Journal à chaque démarrage : 
    API: SYSTEM.storage
Error: unable to rename (/export/.minio.sys/tmp -> /export/.minio.sys/tmp-old/<uuid>) drive is faulty, drive may be faulty, please investigate
FATAL Unable to initialize backend: drive is faulty
  • Longhorn voit le volume sain, trois répliques en marche (relevé du cadrage tools#48). pi2 était à 108–111 % de mémoire pendant les bancs de la veille.
  • Conséquence : aucune vidéo ne part sur les comptes ni ne se relit depuis au moins 26 h (kadans-api renvoie des erreurs de stockage). ~7,7 Go d'objets sur le volume.

Découvert par le cadrage de la migration SeaweedFS (#48), qui ne pouvait pas relever la référence prod au repos.

Décision du fondateur (outil question) : diagnostic ET réparation autorisée

Autorisé : diagnostiquer, puis réparer sans détruire aucune donnée — déplacer le pod hors de pi2, remonter le volume, nettoyer le dossier temporaire interne .minio.sys/tmp. Interdit : supprimer un volume, un PVC, une réplique Longhorn ou un objet ; toucher à un autre namespace que tools pour MinIO et longhorn-system en lecture.

⚠ Le chart tools/minio est synchronisé par ArgoCD (auto-sync, prune) : un correctif durable passe par une PR du dépôt tools, un kubectl patch serait défait.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FDDndoBCcpef952NdHDgaQ

## Constat (2026-09-15, 9 h 35, lecture seule, contexte kubectl `default`) - Pod `tools/minio-56975fd45-s8j8k` sur **pi2** : `0/1 CrashLoopBackOff`, **313 redémarrages en 26 h**. - Image `quay.io/minio/minio:RELEASE.2024-12-18T13-15-44Z`, PVC `minio` 50 Gi Longhorn (`pvc-ebb2605f-0597-43ef-a3d0-6b3c7c8fe3b2`), Bound. - Journal à chaque démarrage : ``` API: SYSTEM.storage Error: unable to rename (/export/.minio.sys/tmp -> /export/.minio.sys/tmp-old/<uuid>) drive is faulty, drive may be faulty, please investigate FATAL Unable to initialize backend: drive is faulty ``` - Longhorn voit le volume sain, trois répliques en marche (relevé du cadrage tools#48). pi2 était à 108–111 % de mémoire pendant les bancs de la veille. - Conséquence : **aucune vidéo ne part sur les comptes ni ne se relit depuis au moins 26 h** (kadans-api renvoie des erreurs de stockage). ~7,7 Go d'objets sur le volume. Découvert par le cadrage de la migration SeaweedFS (#48), qui ne pouvait pas relever la référence prod au repos. ## Décision du fondateur (outil question) : **diagnostic ET réparation autorisée** Autorisé : diagnostiquer, puis réparer **sans détruire aucune donnée** — déplacer le pod hors de pi2, remonter le volume, nettoyer le dossier temporaire interne `.minio.sys/tmp`. **Interdit** : supprimer un volume, un PVC, une réplique Longhorn ou un objet ; toucher à un autre namespace que `tools` pour MinIO et `longhorn-system` en lecture. ⚠ Le chart `tools/minio` est synchronisé par ArgoCD (auto-sync, prune) : un correctif durable passe par une PR du dépôt `tools`, un `kubectl patch` serait défait. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01FDDndoBCcpef952NdHDgaQ
arcodange commented 2026-09-15 09:42:15 +02:00
Author
Owner
Copy Link
Copy Source

Journal d'intervention — 1. diagnostic en lecture (09:39-09:45)

Tous les relevés sont en lecture, avec --context=default ou par ssh pi2 sans sudo.

  • ArgoCD : l'Application minio est Synced / Progressing sur 11b894d, avec auto-sync, prune et selfHeal. Son dernier déploiement date du 2026-09-02 22:01Z. Rien n'a changé côté Git il y a 26 h.
  • Pod : il a démarré le 2026-09-14 à 04:57:29Z. remountRequestedAt du volume Longhorn vaut 04:57:19Z, soit dix secondes avant : Longhorn a relancé le pod. L'instance-manager de pi2 a été recréé à 04:55:42Z.
  • Noyau de pi2 (journalctl -k, heure locale CEST) :
    • 14/09 04:05 : critical medium error en écriture sur le périphérique iSCSI Longhorn (sde, cmd_age=17-23s), puis Aborting journal on device sde-8 et Remounting filesystem read-only (comm minio). Loki (sdh) tombe au même moment.
    • 06:57 : le volume est rattaché en sdb, puis monté rw à 06:58:44.
    • 07:19:18 : nouvelles critical medium error en écriture sur sdb (cmd_age=23s, secteurs 0, 40, 79694064…), puis Aborting journal on device sdb-8, Detected aborted journal (comm minio), et 07:19:41 Remounting filesystem read-only.
    • 07:31 : error -5 reading directory block sur l'inode 2.
    • 15/09 08:41 : error count since last fsck: 2.
  • État actuel : /sys/fs/ext4/sdb/errors_count = 2. Le même montage ext4 au journal abandonné est toujours en place : aucun démontage depuis 07:19 le 14/09. Un redémarrage de conteneur ne démonte pas le volume, d'où les 314 échecs identiques.
  • Longhorn : volume attached sur pi2, healthy, 3 répliques running. La réplique pi2 a lastFailedAt 2026-09-14T05:07:55Z, redevenue saine à 06:06:45Z. Les disques Longhorn sont sur /mnt/arcodange (sda1, 49 %) : ni volume plein ni disque plein.
  • pi2 : 109 % de mémoire (top), 129 Mi libres, pas de swap. Aucune ligne OOM dans le noyau, aucune condition de pression sur le nœud. / est à 91 %.

Hypothèse de travail : le moteur Longhorn, sur un pi2 saturé en mémoire, n'a pas répondu à temps. Les E/S ont expiré en medium error, et ext4 a abandonné son journal. C'est le même mécanisme que tools#31. Les données Longhorn sont saines, mais le système de fichiers reste mort tant qu'il n'est pas démonté.

2. Intention : pod de débogage en lecture seule

kubectl --context=default -n tools apply -f debug-minio-ro.yaml
  • Pod debug-minio-ro, image busybox:1.36, sur nodeName: pi2.
  • PVC minio monté en readOnly: true (RWO : même nœud, donc autorisé).
  • Commande sleep 3600.
  • Relevés prévus : ls -la /export/.minio.sys/{tmp,tmp-old}, df, /proc/mounts, et un test d'écriture impossible par construction.
## Journal d'intervention — 1. diagnostic en lecture (09:39-09:45) Tous les relevés sont en lecture, avec `--context=default` ou par `ssh pi2` sans sudo. - **ArgoCD** : l'Application `minio` est `Synced / Progressing` sur `11b894d`, avec auto-sync, `prune` et `selfHeal`. Son dernier déploiement date du **2026-09-02 22:01Z**. **Rien n'a changé côté Git il y a 26 h.** - **Pod** : il a démarré le **2026-09-14 à 04:57:29Z**. `remountRequestedAt` du volume Longhorn vaut **04:57:19Z**, soit dix secondes avant : Longhorn a relancé le pod. L'instance-manager de pi2 a été recréé à **04:55:42Z**. - **Noyau de pi2** (`journalctl -k`, heure locale CEST) : - **14/09 04:05** : `critical medium error` en écriture sur le périphérique iSCSI Longhorn (`sde`, `cmd_age=17-23s`), puis `Aborting journal on device sde-8` et `Remounting filesystem read-only` (comm minio). Loki (`sdh`) tombe au même moment. - **06:57** : le volume est rattaché en `sdb`, puis **monté rw à 06:58:44**. - **07:19:18** : nouvelles `critical medium error` en écriture sur `sdb` (`cmd_age=23s`, secteurs 0, 40, 79694064…), puis `Aborting journal on device sdb-8`, `Detected aborted journal` (comm minio), et **07:19:41 `Remounting filesystem read-only`**. - **07:31** : `error -5 reading directory block` sur l'inode 2. - **15/09 08:41** : `error count since last fsck: 2`. - **État actuel** : `/sys/fs/ext4/sdb/errors_count = 2`. **Le même montage ext4 au journal abandonné est toujours en place** : aucun démontage depuis 07:19 le 14/09. Un redémarrage de conteneur ne démonte pas le volume, d'où les 314 échecs identiques. - **Longhorn** : volume `attached` sur pi2, `healthy`, 3 répliques `running`. La réplique pi2 a `lastFailedAt 2026-09-14T05:07:55Z`, redevenue saine à 06:06:45Z. Les disques Longhorn sont sur `/mnt/arcodange` (sda1, 49 %) : **ni volume plein ni disque plein**. - **pi2** : 109 % de mémoire (`top`), 129 Mi libres, **pas de swap**. Aucune ligne OOM dans le noyau, aucune condition de pression sur le nœud. `/` est à 91 %. **Hypothèse de travail** : le moteur Longhorn, sur un pi2 saturé en mémoire, n'a pas répondu à temps. Les E/S ont expiré en `medium error`, et ext4 a abandonné son journal. C'est le **même mécanisme que tools#31**. Les données Longhorn sont saines, mais le système de fichiers reste mort tant qu'il n'est pas démonté. ## 2. Intention : pod de débogage en lecture seule ``` kubectl --context=default -n tools apply -f debug-minio-ro.yaml ``` - Pod `debug-minio-ro`, image `busybox:1.36`, sur `nodeName: pi2`. - PVC `minio` monté en `readOnly: true` (RWO : même nœud, donc autorisé). - Commande `sleep 3600`. - Relevés prévus : `ls -la /export/.minio.sys/{tmp,tmp-old}`, `df`, `/proc/mounts`, et un test d'écriture impossible par construction.
arcodange commented 2026-09-15 09:43:26 +02:00
Author
Owner
Copy Link
Copy Source

2. Résultat : pod de débogage (09:43)

kubectl --context=default -n tools apply -f debug-minio-ro.yaml → code 0. wait Ready → 0, exec → 0.

  • /proc/mounts du pod : ext4 ro,relatime, en lecture seule par construction (readOnly: true).
  • df : 48,9 G, 7,6 G utilisés (16 %), 41,3 G libres. Inodes à 0 % (7 570 sur 3,27 M). Le volume n'est pas plein.
  • Racine /export : .minio.sys, kadans-videos et lost+found. Tout appartient à 1000:1000, comme le securityContext. Pas de changement de droits.
  • .minio.sys : buckets, config, format.json, multipart, pool.bin et tmp, tous présents.
  • .minio.sys/tmp pèse 420 K. Il contient .trash (28 entrées), 5157c459-… (dossier) et b2f621ef-… (2 049 octets). Les dates vont jusqu'au 14/09 05:18Z, soit une minute avant l'abandon du journal (07:19 CEST).
  • .minio.sys/tmp-old n'existe pas. Le renommage tmp → tmp-old/<uuid> échoue parce qu'il ne peut rien écrire. MinIO traduit cette erreur d'écriture par « drive is faulty ».
  • touch /export/.ecriture-test → Read-only file system, code 1 : attendu, par construction.

Cause (prouvée)

  1. Le 14/09 à 07:07 CEST (05:07Z), le moteur Longhorn de pi2 logge R/W Timeout. No response received in 8s sur sa réplique locale et la passe en ERR.
  2. À 07:19, les écritures de MinIO restent bloquées 23 s et reviennent au noyau en critical medium error. ext4 abandonne son journal et passe le système de fichiers en lecture seule.
  3. Le même incident avait déjà eu lieu à 04:05. Longhorn avait alors remonté le volume (06:57), et la panne est revenue vingt minutes plus tard.
  4. Depuis, le montage mort n'a jamais été démonté. Les 314 redémarrages de conteneur rouvrent le même montage, qui refuse toute écriture.

Hypothèses écartées, mesures à l'appui :

  • volume plein (16 %) ;
  • disque Longhorn plein (49 %) ;
  • droits ou propriétaire changés (1000:1000 partout) ;
  • volume attaché ailleurs (attaché à pi2, un seul montage) ;
  • changement Git ou ArgoCD (aucun depuis le 02/09).

Hypothèse retenue comme terrain : pi2 est saturé en mémoire (109 %, pas de swap, 129 Mi libres) et porte le moteur et une réplique. Il ne tient pas le délai de 8 s de Longhorn. Aucun OOM noyau n'est journalisé : c'est de la lenteur, pas un processus tué.

3. Plan de réparation (le plus petit qui traite la cause)

  • Démonter puis remonter le volume : au remontage, ext4 rejoue son journal. Pour cela, le pod MinIO doit quitter le nœud.
  • Ne pas revenir sur pi2.
  • Les deux se font en un seul geste durable, par PR sur minio/templates/deployment.yaml : une affinité kubernetes.io/hostname NotIn [pi2].
    • ArgoCD (selfHeal) défait un kubectl patch, mais il appliquera la PR lui-même.
    • Avec la stratégie Recreate, l'ancien pod s'arrête, le volume se détache de pi2, et le nouveau pod le rattache sur pi1 ou pi3.
  • Aucune suspension d'ArgoCD n'est nécessaire.
  • Aucun nettoyage de tmp n'est prévu : il n'est pas en cause, car il est simplement impossible à renommer tant que le système de fichiers est en lecture seule.

Intention suivante : kubectl --context=default -n tools delete pod debug-minio-ro. Il tient le volume sur pi2 et bloquerait le rattachement ailleurs (RWO).

## 2. Résultat : pod de débogage (09:43) `kubectl --context=default -n tools apply -f debug-minio-ro.yaml` → **code 0**. `wait Ready` → 0, `exec` → 0. - `/proc/mounts` du pod : `ext4 ro,relatime`, en lecture seule par construction (`readOnly: true`). - `df` : **48,9 G, 7,6 G utilisés (16 %), 41,3 G libres**. Inodes à 0 % (7 570 sur 3,27 M). **Le volume n'est pas plein.** - Racine `/export` : `.minio.sys`, `kadans-videos` et `lost+found`. Tout appartient à `1000:1000`, comme le `securityContext`. **Pas de changement de droits.** - `.minio.sys` : `buckets`, `config`, `format.json`, `multipart`, `pool.bin` et `tmp`, **tous présents**. - `.minio.sys/tmp` pèse 420 K. Il contient `.trash` (28 entrées), `5157c459-…` (dossier) et `b2f621ef-…` (2 049 octets). Les dates vont jusqu'au **14/09 05:18Z**, soit **une minute avant l'abandon du journal (07:19 CEST)**. - **`.minio.sys/tmp-old` n'existe pas.** Le renommage `tmp → tmp-old/<uuid>` échoue parce qu'il ne peut rien écrire. MinIO traduit cette erreur d'écriture par « drive is faulty ». - `touch /export/.ecriture-test` → `Read-only file system`, code 1 : attendu, par construction. ## Cause (prouvée) 1. Le **14/09 à 07:07 CEST (05:07Z)**, le moteur Longhorn de pi2 logge `R/W Timeout. No response received in 8s` sur sa réplique locale et la passe en `ERR`. 2. À **07:19**, les écritures de MinIO restent bloquées 23 s et reviennent au noyau en `critical medium error`. ext4 **abandonne son journal** et passe le système de fichiers **en lecture seule**. 3. Le même incident avait déjà eu lieu à **04:05**. Longhorn avait alors remonté le volume (06:57), et la panne est revenue vingt minutes plus tard. 4. Depuis, **le montage mort n'a jamais été démonté**. Les 314 redémarrages de conteneur rouvrent le même montage, qui refuse toute écriture. Hypothèses **écartées**, mesures à l'appui : - volume plein (16 %) ; - disque Longhorn plein (49 %) ; - droits ou propriétaire changés (1000:1000 partout) ; - volume attaché ailleurs (attaché à pi2, un seul montage) ; - changement Git ou ArgoCD (aucun depuis le 02/09). Hypothèse **retenue comme terrain** : pi2 est saturé en mémoire (109 %, pas de swap, 129 Mi libres) et porte le moteur **et** une réplique. Il ne tient pas le délai de 8 s de Longhorn. Aucun OOM noyau n'est journalisé : c'est de la lenteur, pas un processus tué. ## 3. Plan de réparation (le plus petit qui traite la cause) - **Démonter puis remonter le volume** : au remontage, ext4 rejoue son journal. Pour cela, le pod MinIO doit quitter le nœud. - **Ne pas revenir sur pi2.** - Les deux se font en un seul geste durable, par **PR sur `minio/templates/deployment.yaml`** : une affinité `kubernetes.io/hostname NotIn [pi2]`. - ArgoCD (`selfHeal`) défait un `kubectl patch`, mais il appliquera la PR lui-même. - Avec la stratégie `Recreate`, l'ancien pod s'arrête, le volume se détache de pi2, et le nouveau pod le rattache sur pi1 ou pi3. - **Aucune suspension d'ArgoCD n'est nécessaire.** - Aucun nettoyage de `tmp` n'est prévu : il n'est pas en cause, car il est simplement impossible à renommer tant que le système de fichiers est en lecture seule. **Intention suivante :** `kubectl --context=default -n tools delete pod debug-minio-ro`. Il tient le volume sur pi2 et bloquerait le rattachement ailleurs (RWO).
arcodange commented 2026-09-15 09:44:38 +02:00
Author
Owner
Copy Link
Copy Source

Relais (09:47) : session arrêtée par manque de tokens, aucune réparation lancée

Cause prouvée (preuves dans les deux commentaires précédents) :

  • Le 14/09 à 07:07 CEST, le moteur Longhorn de pi2 dépasse son délai (R/W Timeout 8s). pi2 est à 109 % de mémoire, sans swap.
  • À 07:19, les écritures reviennent en critical medium error. ext4 abandonne son journal (Aborting journal on device sdb-8, Remounting filesystem read-only).
  • Ce montage mort n'a jamais été démonté. Le renommage tmp → tmp-old échoue en lecture seule, et MinIO le signale par « drive is faulty ».
  • Hypothèses écartées : volume plein (16 %), droits changés (1000:1000), disque Longhorn plein (49 %), changement ArgoCD.

Actions faites :

  • Lecture seule partout.
  • Seule écriture : le pod tools/debug-minio-ro (busybox, PVC en readOnly). Créé (code 0), puis supprimé (code 0, NotFound vérifié).

État vérifié à 09:47 :

  • Pod minio-56975fd45-s8j8k sur pi2 : CrashLoopBackOff, 314 redémarrages.
  • Volume attached, healthy, sur pi2.
  • ArgoCD minio : Synced / Progressing, auto-sync avec prune et selfHeal. Rien de suspendu.
  • Aucun pod de débogage restant.

Prochaine étape exacte : sortir MinIO de pi2 par une PR. ArgoCD l'applique, et la stratégie Recreate démonte le volume : ext4 rejouera son journal au remontage sur pi1 ou pi3.

  1. Un brouillon non commité existe dans le worktree /Users/gabrielradureau/Work/Arcodange/tools/.claude/worktrees/incident-minio, branche arcodange/incident-minio, partie de origin/main 11b894d. Il ajoute à minio/templates/deployment.yaml une affinity.nodeAffinity requise kubernetes.io/hostname NotIn [pi2], avec une préférence pour pi3.
  2. Relire le rendu : helm template minio/ | grep -A20 affinity. Puis commit, push, et PR vers main avec le MCP Gitea. Vérifier que la CI Helm Charts est verte, puis fusionner.
  3. Suivre la bascule :
    • kubectl --context=default -n tools get pods -l app=minio -o wide -w ;
    • kubectl --context=default -n longhorn-system get volumes.longhorn.io pvc-ebb2605f-0597-43ef-a3d0-6b3c7c8fe3b2 -o jsonpath='{.status.state} {.status.currentNodeID}'.
  4. Vérifier, dans l'ordre :
    • le pod est 1/1 Ready ;
    • kubectl --context=default -n tools logs deploy/minio ne contient plus « drive is faulty » ;
    • journalctl -k du nouveau nœud montre un montage ext4 propre ;
    • kubectl --context=default -n kadans logs deploy/kadans-api ne montre plus d'erreur de stockage.
  5. Si le remontage échoue sur des erreurs ext4, ne rien réparer : un fsck avec écriture exige l'accord du fondateur.

Ce qui exige le fondateur :

  • l'accord pour un fsck avec écriture, seulement si le remontage échoue ;
  • à terme, le terrain lui-même : pi2 sature en mémoire. Les volumes Longhorn de loki et d'autres pods y ont subi la même panne à 04:05.
## Relais (09:47) : session arrêtée par manque de tokens, aucune réparation lancée **Cause prouvée** (preuves dans les deux commentaires précédents) : - Le 14/09 à 07:07 CEST, le moteur Longhorn de pi2 dépasse son délai (`R/W Timeout 8s`). pi2 est à 109 % de mémoire, sans swap. - À 07:19, les écritures reviennent en `critical medium error`. ext4 abandonne son journal (`Aborting journal on device sdb-8`, `Remounting filesystem read-only`). - Ce montage mort n'a jamais été démonté. Le renommage `tmp → tmp-old` échoue en lecture seule, et MinIO le signale par « drive is faulty ». - Hypothèses écartées : volume plein (16 %), droits changés (1000:1000), disque Longhorn plein (49 %), changement ArgoCD. **Actions faites** : - Lecture seule partout. - Seule écriture : le pod `tools/debug-minio-ro` (busybox, PVC en `readOnly`). Créé (code 0), puis **supprimé** (code 0, `NotFound` vérifié). **État vérifié à 09:47** : - Pod `minio-56975fd45-s8j8k` sur pi2 : `CrashLoopBackOff`, 314 redémarrages. - Volume `attached`, `healthy`, sur pi2. - ArgoCD `minio` : `Synced / Progressing`, auto-sync avec `prune` et `selfHeal`. **Rien de suspendu.** - Aucun pod de débogage restant. **Prochaine étape exacte** : sortir MinIO de pi2 par une PR. ArgoCD l'applique, et la stratégie `Recreate` démonte le volume : ext4 rejouera son journal au remontage sur pi1 ou pi3. 1. Un brouillon **non commité** existe dans le worktree `/Users/gabrielradureau/Work/Arcodange/tools/.claude/worktrees/incident-minio`, branche `arcodange/incident-minio`, partie de `origin/main` `11b894d`. Il ajoute à `minio/templates/deployment.yaml` une `affinity.nodeAffinity` requise `kubernetes.io/hostname NotIn [pi2]`, avec une préférence pour pi3. 2. Relire le rendu : `helm template minio/ | grep -A20 affinity`. Puis commit, push, et PR vers `main` avec le MCP Gitea. Vérifier que la CI `Helm Charts` est verte, puis fusionner. 3. Suivre la bascule : - `kubectl --context=default -n tools get pods -l app=minio -o wide -w` ; - `kubectl --context=default -n longhorn-system get volumes.longhorn.io pvc-ebb2605f-0597-43ef-a3d0-6b3c7c8fe3b2 -o jsonpath='{.status.state} {.status.currentNodeID}'`. 4. Vérifier, dans l'ordre : - le pod est `1/1 Ready` ; - `kubectl --context=default -n tools logs deploy/minio` ne contient plus « drive is faulty » ; - `journalctl -k` du nouveau nœud montre un montage ext4 propre ; - `kubectl --context=default -n kadans logs deploy/kadans-api` ne montre plus d'erreur de stockage. 5. Si le remontage échoue sur des erreurs ext4, **ne rien réparer** : un `fsck` avec écriture exige l'accord du fondateur. **Ce qui exige le fondateur** : - l'accord pour un `fsck` avec écriture, seulement si le remontage échoue ; - à terme, le terrain lui-même : pi2 sature en mémoire. Les volumes Longhorn de loki et d'autres pods y ont subi la même panne à 04:05.
arcodange commented 2026-09-15 10:52:03 +02:00
Author
Owner
Copy Link
Copy Source

Clôture (10:52) : MinIO tourne sur pi3, ext4 remonté proprement, lecture et écriture vérifiées

Ce qui a été fait

  1. PR #50 : affinité requise kubernetes.io/hostname NotIn [pi2], avec une préférence pour pi3.
    • Rendu helm template comparé avant/après : seul le bloc affinity change. Recreate est confirmé.
    • CI « Helm Charts » run 7871 : success, et le job minio a bien exécuté Helm template.
    • Fusionnée en squash : 558521ee3fa2b61223ad67858bd8068ca7025442.
  2. ArgoCD a synchronisé seul, 5 min 38 s après la fusion. Rien n'a été forcé ni suspendu.
  3. Bascule (heures UTC) :
    • 08:40:18 : l'ancien pod est supprimé par le ReplicaSet.
    • Le volume se détache de pi2. Côté noyau de pi2, le montage mort est enfin démonté (10:40:35 CEST EXT4-fs (sdb): unmounting filesystem 0e5e02fc…).
    • Deux refus transitoires, attendus avec Recreate : Multi-Attach, puis not ready for workloads.
    • 08:41:05 : le volume est rattaché sur pi3.
    • 08:41:25 : le nouveau pod est 1/1 Ready.

État vérifié (lecture seule sauf mention)

  • Pod : minio-646d87c9bc-hscwt 1/1 Running, 0 redémarrage, sur pi3.
  • Volume Longhorn : attached pi3 healthy, trois répliques running (pi1, pi2, pi3).
  • ArgoCD : minio est Synced / Healthy sur 558521e. Il était Progressing depuis le 02/09.
  • Journal MinIO : 9 lignes (bannière et adresses), 0 occurrence de « faulty », aucune erreur.
  • Noyau de pi3 : EXT4-fs (sdd): mounted filesystem 0e5e02fc… r/w. /sys/fs/ext4/sdd/errors_count = 0.
  • ⚠ Un fsck a tourné, mais ce n'est pas nous qui l'avons lancé. Le plugin CSI Longhorn de pi3 journalise Device /dev/longhorn/pvc-ebb2605f… has errors which were corrected by fsck : c'est le fsck -a automatique de kubelet (mount-utils) avant tout montage ext4, en mode preen, qui ne fait que les corrections sûres. Nous n'avons lancé aucun fsck. Contrôle de ce qu'il a pu déplacer :
    • lost+found est vide ;
    • 16 % d'occupation, 7 516 inodes. Avant : 7 570 ; l'écart correspond au ménage de tmp fait par MinIO au démarrage ;
    • 2 370 objets, 7,6 GiB dans kadans-videos, soit le même volume qu'avant l'incident ;
    • 0 téléversement incomplet.
  • Lecture complète de 53 objets (les 30 de septembre et 1 sur 97 du reste) : 0 échec, 151 143 764 octets lus.
  • Chemin du navigateur : une URL présignée GET est générée dans le pod, jamais imprimée, puis appelée via s3.arcodange.fr (Cloudflare → Traefik → MinIO) sur un travail.mp4 :
    • Range 0-1023 → 206, 1 024 octets, video/mp4 ;
    • lecture complète → 200, 1 123 533 octets.
  • Santé : /minio/health/cluster/read → 200 en interne et via s3.arcodange.lab ; s3.arcodange.fr/minio/health/live → 200.
  • Écriture (seule écriture de l'intervention) :
    • objet témoin kadans-videos/temoin-incident-tools-49/ecriture-apres-bascule-pi3.txt (72 o) : écrit, puis relu à l'identique ;
    • supprimé avec mc rm --version-id null, ce qui ne laisse aucune version ni marqueur (le versionnage du seau est suspendu) ;
    • préfixe vide après suppression, et le seau compte de nouveau 2 370 objets.
  • kadans-api :
    • logs --since=15m est vide. Ce n'est pas une preuve : l'API ne journalise pas ses requêtes ;
    • la vigie (:9101/metrics) montre kadans_api_magasin_erreurs_total à 0 partout, mais aussi depots_total à 0. Il n'y a eu aucun trafic depuis son redémarrage de 01:48, donc ces compteurs ne prouvent rien non plus ;
    • la preuve fonctionnelle est donc celle du chemin S3 ci-dessus. Le premier vrai dépôt depuis l'app reste à observer.

Ce qui reste

1. ⚠⚠ Nouvel incident trouvé : tools/prometheus-server a la MÊME panne, sur pi1, depuis 27 h. Non traité : hors de l'autorisation (MinIO seul).

  • Son volume pvc-015eabf4 est monté ro sur pi1 (/sys/fs/ext4/sdb, errors_count=1, ext4_journal_check_start, 14/09 05:16:54Z).
  • Le conteneur prometheus-server est ready=false avec 0 redémarrage. Il journalise en boucle write to WAL: … input/output error.
  • Prometheus n'enregistre plus rien depuis le 14/09.
  • Le moteur de ce volume est sur pi1, mais il a une réplique sur pi2 : un réplica lent suffit à bloquer les écritures.
  • Le remède serait le même : démonter puis remonter, en redéployant le pod. Il exige l'accord du fondateur.

2. Les autres volumes touchés le 14/09 sur pi2 ont récupéré :

  • loki (pvc-e120d232, fs f868114b) : journal abandonné à 04:05 et à 06:55, remonté rw par Longhorn à 06:59. Il est rw aujourd'hui, errors_count=0, et loki-0 est Ready.
  • url-shortener (pvc-cdd434d1, fs e658fc49) : journal abandonné à 04:06, remonté rw sur pi1 à 04:08. errors_count=0, pod 1/1.

3. Deux volumes Longhorn orphelins restent attachés à pi2, et leurs moteurs y consomment de la mémoire :

  • pvc-04e9b068 (ancien prometheus-server) et pvc-af0e2c87 (ancien redis-storage-redis-0) ;
  • leur PV n'existe plus, mais leur VolumeAttachment est toujours attached ;
  • rien n'a été touché ; les retirer demande une décision.

4. Le terrain n'est pas traité.

  • pi2 est à 108 % de mémoire, sans swap (143 Mi libres à 10:50).
  • MinIO n'y a plus son moteur, mais son volume y garde une réplique, comme tous les volumes à trois répliques. Un pi2 lent peut encore ralentir les écritures de MinIO.
  • Le correctif durable (mémoire de pi2, swap, placement des répliques ou des pods lourds) exige le fondateur.

5. La migration SeaweedFS (#48) peut relever sa référence prod.

Rien de suspendu. Aucun pod de débogage. Aucun volume, PVC, réplique ni objet existant n'a été touché.

🤖 Generated with Claude Code

## Clôture (10:52) : MinIO tourne sur pi3, ext4 remonté proprement, lecture et écriture vérifiées ### Ce qui a été fait 1. **PR #50** : affinité requise `kubernetes.io/hostname NotIn [pi2]`, avec une préférence pour pi3. - Rendu `helm template` comparé avant/après : seul le bloc `affinity` change. `Recreate` est confirmé. - CI « Helm Charts » run 7871 : `success`, et le job `minio` a bien exécuté `Helm template`. - **Fusionnée en squash : `558521ee3fa2b61223ad67858bd8068ca7025442`.** 2. **ArgoCD** a synchronisé seul, 5 min 38 s après la fusion. Rien n'a été forcé ni suspendu. 3. **Bascule** (heures UTC) : - 08:40:18 : l'ancien pod est supprimé par le ReplicaSet. - Le volume se détache de pi2. Côté noyau de pi2, le montage mort est enfin démonté (`10:40:35 CEST EXT4-fs (sdb): unmounting filesystem 0e5e02fc…`). - Deux refus transitoires, attendus avec `Recreate` : `Multi-Attach`, puis `not ready for workloads`. - 08:41:05 : le volume est rattaché sur **pi3**. - 08:41:25 : le nouveau pod est `1/1 Ready`. ### État vérifié (lecture seule sauf mention) - **Pod** : `minio-646d87c9bc-hscwt` `1/1 Running`, 0 redémarrage, sur **pi3**. - **Volume** Longhorn : `attached pi3 healthy`, trois répliques `running` (pi1, pi2, pi3). - **ArgoCD** : `minio` est **`Synced / Healthy`** sur `558521e`. Il était `Progressing` depuis le 02/09. - **Journal MinIO** : 9 lignes (bannière et adresses), **0 occurrence de « faulty »**, aucune erreur. - **Noyau de pi3** : `EXT4-fs (sdd): mounted filesystem 0e5e02fc… r/w`. `/sys/fs/ext4/sdd/errors_count = 0`. - ⚠ **Un fsck a tourné, mais ce n'est pas nous qui l'avons lancé.** Le plugin CSI Longhorn de pi3 journalise `Device /dev/longhorn/pvc-ebb2605f… has errors which were corrected by fsck` : c'est le `fsck -a` automatique de kubelet (mount-utils) avant tout montage ext4, en mode *preen*, qui ne fait que les corrections sûres. Nous n'avons lancé aucun fsck. Contrôle de ce qu'il a pu déplacer : - `lost+found` est **vide** ; - 16 % d'occupation, 7 516 inodes. Avant : 7 570 ; l'écart correspond au ménage de `tmp` fait par MinIO au démarrage ; - **2 370 objets, 7,6 GiB** dans `kadans-videos`, soit le même volume qu'avant l'incident ; - 0 téléversement incomplet. - **Lecture complète** de 53 objets (les 30 de septembre et 1 sur 97 du reste) : **0 échec, 151 143 764 octets lus**. - **Chemin du navigateur** : une URL présignée GET est générée dans le pod, jamais imprimée, puis appelée via `s3.arcodange.fr` (Cloudflare → Traefik → MinIO) sur un `travail.mp4` : - `Range 0-1023` → **206**, 1 024 octets, `video/mp4` ; - lecture complète → **200**, 1 123 533 octets. - **Santé** : `/minio/health/cluster/read` → 200 en interne et via `s3.arcodange.lab` ; `s3.arcodange.fr/minio/health/live` → 200. - **Écriture (seule écriture de l'intervention)** : - objet témoin `kadans-videos/temoin-incident-tools-49/ecriture-apres-bascule-pi3.txt` (72 o) : écrit, puis relu à l'identique ; - supprimé avec `mc rm --version-id null`, ce qui ne laisse aucune version ni marqueur (le versionnage du seau est suspendu) ; - préfixe vide après suppression, et le seau compte de nouveau 2 370 objets. - **kadans-api** : - `logs --since=15m` est **vide**. Ce n'est pas une preuve : l'API ne journalise pas ses requêtes ; - la vigie (`:9101/metrics`) montre `kadans_api_magasin_erreurs_total` à 0 partout, mais aussi `depots_total` à 0. **Il n'y a eu aucun trafic depuis son redémarrage de 01:48**, donc ces compteurs ne prouvent rien non plus ; - la preuve fonctionnelle est donc celle du chemin S3 ci-dessus. **Le premier vrai dépôt depuis l'app reste à observer.** ### Ce qui reste **1. ⚠⚠ Nouvel incident trouvé : `tools/prometheus-server` a la MÊME panne, sur pi1, depuis 27 h. Non traité : hors de l'autorisation (MinIO seul).** - Son volume `pvc-015eabf4` est monté **`ro`** sur pi1 (`/sys/fs/ext4/sdb`, `errors_count=1`, `ext4_journal_check_start`, 14/09 05:16:54Z). - Le conteneur `prometheus-server` est `ready=false` avec 0 redémarrage. Il journalise en boucle `write to WAL: … input/output error`. - **Prometheus n'enregistre plus rien depuis le 14/09.** - Le moteur de ce volume est sur pi1, mais **il a une réplique sur pi2** : un réplica lent suffit à bloquer les écritures. - Le remède serait le même : démonter puis remonter, en redéployant le pod. **Il exige l'accord du fondateur.** **2. Les autres volumes touchés le 14/09 sur pi2 ont récupéré :** - **loki** (`pvc-e120d232`, fs `f868114b`) : journal abandonné à 04:05 et à 06:55, remonté `rw` par Longhorn à 06:59. Il est `rw` aujourd'hui, `errors_count=0`, et `loki-0` est Ready. - **url-shortener** (`pvc-cdd434d1`, fs `e658fc49`) : journal abandonné à 04:06, remonté `rw` sur pi1 à 04:08. `errors_count=0`, pod `1/1`. **3. Deux volumes Longhorn orphelins restent attachés à pi2**, et leurs moteurs y consomment de la mémoire : - `pvc-04e9b068` (ancien `prometheus-server`) et `pvc-af0e2c87` (ancien `redis-storage-redis-0`) ; - leur PV n'existe plus, mais leur `VolumeAttachment` est toujours `attached` ; - rien n'a été touché ; les retirer demande une décision. **4. Le terrain n'est pas traité.** - pi2 est à 108 % de mémoire, sans swap (143 Mi libres à 10:50). - MinIO n'y a plus son moteur, mais **son volume y garde une réplique**, comme tous les volumes à trois répliques. Un pi2 lent peut encore ralentir les écritures de MinIO. - Le correctif durable (mémoire de pi2, swap, placement des répliques ou des pods lourds) exige le fondateur. **5.** La migration SeaweedFS (#48) peut relever sa référence prod. Rien de suspendu. Aucun pod de débogage. Aucun volume, PVC, réplique ni objet existant n'a été touché. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
arcodange commented 2026-09-15 12:03:37 +02:00
Author
Owner
Copy Link
Copy Source

Suite (12:04) : Prometheus réparé, orphelins détachés, mémoire de pi2 relevée

Réponses du fondateur (2026-09-15) :

  1. Prometheus : « Oui, même remède, sans perte ».
  2. Orphelins : « Les détacher, sans les supprimer ».
  3. Mémoire de pi2 : « Un relevé et un plan, rien d'appliqué ».

1. Prometheus : réparé

  • Aggravation avant la réparation. À 08:52Z, la sonde de vivacité a redémarré le conteneur. Il était depuis en CrashLoopBackOff (18 redémarrages) : open /data/queries.active: read-only file system puis panic: Unable to create mmap-ed active query log.
  • PR #51 (prometheus/values.yaml → server.affinity) :
    • requise NotIn [pi2], préférence de poids 100 pour pi3 ;
    • rendu helm template comparé avant/après : seul ce bloc change, Recreate est confirmé ;
    • CI run 7903 verte, avec Helm template exécuté ;
    • fusionnée en squash : e64d70856579a3d5ce77fed142ed594efbe9cefd.
  • Pourquoi un autre nœud : recréé sur pi1, le pod neuf aurait pu reprendre le montage de staging mort, puisqu'il est créé dès que l'ancien est terminal. Sur pi3, le volume est forcément détaché puis rattaché.
  • Bascule : ArgoCD a synchronisé seul à 09:48Z. Refus transitoires Multi-Attach, puis rattachement sur pi3 à 09:51:37Z. Pod prometheus-server-86c78bd477-kclw6 2/2 Ready à 09:52Z.
  • Montage :
    • pi3 : EXT4-fs (sdf): mounted filesystem a88a86d3… r/w, errors_count=0, /proc/mounts en rw. Aucune correction fsck n'est journalisée par le plugin CSI cette fois.
    • Sur pi1, l'ancien sdb (errors_count=1) est libéré.
  • Données :
    • Found healthy block pour les 20 blocs, WAL rejoué (segment=1839..1842, checkpoint chargé) ;
    • aucune ligne repair/corrupt, 0 level=ERROR, TSDB started puis Server is ready ;
    • seul avertissement : lockfile from a previous execution already existed. It was replaced.
  • Ingestion vérifiée (09:57Z) :
    • up : 24 séries, âge du dernier échantillon entre 0 et 59 s ;
    • sum(rate(prometheus_tsdb_head_samples_appended_total[3m])) = 3 475 échantillons/s ; prometheus_tsdb_head_series = 208 802 ;
    • cibles actives : 22 up, 2 down ;
    • les deux down l'étaient déjà avant l'incident (requête up == 0 au 14/09 03:00Z) : kadans-worker-mac (192.168.1.103:9105, poste éteint) et step-issuer (10.42.1.22:8080, connexion refusée).
  • Trou de données : count(up) n'a aucun point entre le 14/09 ~05:16Z et le 15/09 09:52Z. Ces échantillons n'ont jamais été écrits et ne sont pas récupérables.
  • Volume :
    • pendant la bascule, la réplique de pi2 a été reconstruite (WO, 17 %) à partir de celle de pi3 ;
    • à 09:57:53Z, le volume est healthy, avec 3 répliques RW.
  • ArgoCD : prometheus Synced / Healthy. Il était Progressing avant.

2. Volumes orphelins : détachés, rien de supprimé

Volume Longhorn (nom complet) Ancien PVC Taille / utilisé Répliques après détachement
pvc-04e9b068-c246-4159-92de-51b03ed1673f tools/prometheus-server (avril) 8 Gi / 7,27 Gi pi1, pi2, pi3 : stopped, 7,3 G chacune sur disque
pvc-af0e2c87-0727-401f-bbb0-03226cacd795 tools/redis-storage-redis-0 (avril) 1 Gi / 50 Mi pi1, pi2, pi3 : stopped, 51 M chacune sur disque

  • Pourquoi ils restaient attachés : leurs VolumeAttachment Kubernetes sont en suppression depuis le 21/04 et le 09/05. Le finaliseur external-attacher/driver-longhorn-io échoue sur persistentvolume … not found, car le PV n'existe plus. Le ticket csi-attacher restait donc posé dans Longhorn.

  • Geste : API Longhorn (longhorn-frontend) POST /v1/volumes/<nom>?action=detach avec {"hostId":"","forceDetach":true}, HTTP 200 pour les deux (09:55:39Z et 09:56:04Z). C'est le « Detach » de l'interface Longhorn.

  • Vérifié :

    • state=detached 10 à 14 s plus tard, tickets {} ;
    • plus aucun processus moteur, réplique ou sync-agent pour ces volumes sur les trois nœuds, plus de /dev/longhorn/… ;
    • les répliques existent toujours, avec les tailles ci-dessus, relevées par du en lecture sur chaque nœud ;
    • allow-recurring-job-while-volume-detached=false : rien ne les rattachera seul.

  • Mémoire :

    pi2 pi1 pi3
    MemAvailable avant (09:54Z) 1 505 Mi 2 562 Mi 2 841 Mi
    MemAvailable après (10:00Z) 1 577 Mi 2 620 Mi 2 906 Mi
    RSS des processus orphelins libéré ~107 Mi ~83 Mi ~123 Mi

    Le gain sur pi2 est de l'ordre du bruit : une reconstruction tournait en même temps.

  • Reste, décision du fondateur :

    • les deux VolumeAttachment bloqués sont toujours là (attached=true, finaliseur) ;
    • les ~22 Gi de répliques orphelines occupent les disques Longhorn ;
    • rien n'a été supprimé.

3. Mémoire de pi2 : issue tools#52 (relevé et plan, rien d'appliqué)

Découverte principale : gvfs-udisks2-volume-monitor (bureau de l'utilisateur pi) occupe 2,54 Gi PSS sur pi2, contre 5–9 Mi sur pi1 et pi3. Il tourne depuis 154 jours et représente un tiers de la RAM du nœud.

⚠ Nouvel incident, non traité : tools#53

ClickHouse (Plausible) : son volume pvc-1251909b… a le journal ext4 abandonné depuis le 04/09, sur pi3 (errors_count=2). Le pod journalise environ 1 500 Input/output error par 10 min, et ArgoCD plausible est Degraded. Le remède serait le même, mais il exige l'accord du fondateur.

Balayage complet des compteurs ext4 des trois nœuds à 10:00Z : aucun autre volume Longhorn monté n'a d'erreur.

Rien de suspendu. Aucun pod de débogage. Aucun volume, PVC, réplique ni objet supprimé.

🤖 Generated with Claude Code

## Suite (12:04) : Prometheus réparé, orphelins détachés, mémoire de pi2 relevée Réponses du fondateur (2026-09-15) : 1. Prometheus : « Oui, même remède, sans perte ». 2. Orphelins : « Les détacher, sans les supprimer ». 3. Mémoire de pi2 : « Un relevé et un plan, rien d'appliqué ». ### 1. Prometheus : réparé - **Aggravation avant la réparation.** À 08:52Z, la sonde de vivacité a redémarré le conteneur. Il était depuis en **CrashLoopBackOff** (18 redémarrages) : `open /data/queries.active: read-only file system` puis `panic: Unable to create mmap-ed active query log`. - **PR #51** (`prometheus/values.yaml` → `server.affinity`) : - requise `NotIn [pi2]`, préférence de poids 100 pour pi3 ; - rendu `helm template` comparé avant/après : seul ce bloc change, `Recreate` est confirmé ; - CI run 7903 verte, avec `Helm template` exécuté ; - **fusionnée en squash : `e64d70856579a3d5ce77fed142ed594efbe9cefd`**. - **Pourquoi un autre nœud** : recréé sur pi1, le pod neuf aurait pu reprendre le montage de staging mort, puisqu'il est créé dès que l'ancien est terminal. Sur pi3, le volume est forcément détaché puis rattaché. - **Bascule** : ArgoCD a synchronisé seul à 09:48Z. Refus transitoires `Multi-Attach`, puis rattachement sur **pi3** à 09:51:37Z. Pod `prometheus-server-86c78bd477-kclw6` **`2/2 Ready`** à 09:52Z. - **Montage** : - pi3 : `EXT4-fs (sdf): mounted filesystem a88a86d3… r/w`, `errors_count=0`, `/proc/mounts` en **`rw`**. Aucune correction `fsck` n'est journalisée par le plugin CSI cette fois. - Sur pi1, l'ancien `sdb` (`errors_count=1`) est libéré. - **Données** : - `Found healthy block` pour **les 20 blocs**, WAL rejoué (`segment=1839..1842`, checkpoint chargé) ; - **aucune ligne `repair`/`corrupt`**, 0 `level=ERROR`, `TSDB started` puis `Server is ready` ; - seul avertissement : `lockfile from a previous execution already existed. It was replaced`. - **Ingestion vérifiée (09:57Z)** : - `up` : 24 séries, âge du dernier échantillon entre 0 et 59 s ; - `sum(rate(prometheus_tsdb_head_samples_appended_total[3m]))` = **3 475 échantillons/s** ; `prometheus_tsdb_head_series` = 208 802 ; - cibles actives : **22 `up`, 2 `down`** ; - les deux `down` l'étaient **déjà avant l'incident** (requête `up == 0` au 14/09 03:00Z) : `kadans-worker-mac` (192.168.1.103:9105, poste éteint) et `step-issuer` (10.42.1.22:8080, connexion refusée). - **Trou de données** : `count(up)` n'a aucun point entre le **14/09 ~05:16Z** et le **15/09 09:52Z**. Ces échantillons n'ont jamais été écrits et ne sont pas récupérables. - **Volume** : - pendant la bascule, la réplique de pi2 a été reconstruite (`WO`, 17 %) à partir de celle de pi3 ; - à 09:57:53Z, le volume est `healthy`, avec 3 répliques `RW`. - **ArgoCD** : `prometheus` **Synced / Healthy**. Il était `Progressing` avant. ### 2. Volumes orphelins : détachés, rien de supprimé | Volume Longhorn (nom complet) | Ancien PVC | Taille / utilisé | Répliques après détachement | |---|---|---|---| | `pvc-04e9b068-c246-4159-92de-51b03ed1673f` | `tools/prometheus-server` (avril) | 8 Gi / 7,27 Gi | pi1, pi2, pi3 : `stopped`, **7,3 G chacune** sur disque | | `pvc-af0e2c87-0727-401f-bbb0-03226cacd795` | `tools/redis-storage-redis-0` (avril) | 1 Gi / 50 Mi | pi1, pi2, pi3 : `stopped`, **51 M chacune** sur disque | - **Pourquoi ils restaient attachés** : leurs `VolumeAttachment` Kubernetes sont en suppression depuis le **21/04** et le **09/05**. Le finaliseur `external-attacher/driver-longhorn-io` échoue sur `persistentvolume … not found`, car le PV n'existe plus. Le ticket `csi-attacher` restait donc posé dans Longhorn. - **Geste** : API Longhorn (`longhorn-frontend`) `POST /v1/volumes/<nom>?action=detach` avec `{"hostId":"","forceDetach":true}`, HTTP 200 pour les deux (09:55:39Z et 09:56:04Z). C'est le « Detach » de l'interface Longhorn. - **Vérifié** : - `state=detached` 10 à 14 s plus tard, tickets `{}` ; - plus aucun processus moteur, réplique ou sync-agent pour ces volumes sur les trois nœuds, plus de `/dev/longhorn/…` ; - les répliques existent toujours, avec les tailles ci-dessus, relevées par `du` en lecture sur chaque nœud ; - `allow-recurring-job-while-volume-detached=false` : rien ne les rattachera seul. - **Mémoire** : | | pi2 | pi1 | pi3 | |---|---|---|---| | `MemAvailable` avant (09:54Z) | 1 505 Mi | 2 562 Mi | 2 841 Mi | | `MemAvailable` après (10:00Z) | 1 577 Mi | 2 620 Mi | 2 906 Mi | | RSS des processus orphelins libéré | ~107 Mi | ~83 Mi | ~123 Mi | Le gain sur pi2 est de l'ordre du bruit : une reconstruction tournait en même temps. - **Reste, décision du fondateur** : - les deux `VolumeAttachment` bloqués sont toujours là (`attached=true`, finaliseur) ; - les ~22 Gi de répliques orphelines occupent les disques Longhorn ; - rien n'a été supprimé. ### 3. Mémoire de pi2 : issue **tools#52** (relevé et plan, rien d'appliqué) Découverte principale : `gvfs-udisks2-volume-monitor` (bureau de l'utilisateur `pi`) occupe **2,54 Gi PSS sur pi2**, contre 5–9 Mi sur pi1 et pi3. Il tourne depuis 154 jours et représente un tiers de la RAM du nœud. ### ⚠ Nouvel incident, non traité : **tools#53** **ClickHouse (Plausible)** : son volume `pvc-1251909b…` a le journal ext4 abandonné depuis le **04/09**, sur pi3 (`errors_count=2`). Le pod journalise environ 1 500 `Input/output error` par 10 min, et ArgoCD `plausible` est `Degraded`. Le remède serait le même, mais il exige l'accord du fondateur. Balayage complet des compteurs ext4 des trois nœuds à 10:00Z : aucun autre volume Longhorn monté n'a d'erreur. Rien de suspendu. Aucun pod de débogage. Aucun volume, PVC, réplique ni objet supprimé. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
arcodange
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: arcodange-org/tools#49