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

Incident (3ᵉ récidive) — MinIO en CrashLoopBackOff ~22 h sur pi3 (« drive is faulty ») : envois de vidéos bloqués ; réparé par remontage le 24/09 09:02 UTC #58

New Issue
Open
opened 2026-09-24 11:06:21 +02:00 by arcodange · 2 comments
arcodange commented 2026-09-24 11:06:21 +02:00
Owner
Copy Link
Copy Source

Constat (2026-09-24, signalé par le fondateur : « l'upload de vidéos depuis mon téléphone semble bloqué »)

  • Pod tools/minio-646d87c9bc-hscwt sur pi3 : 0/1 CrashLoopBackOff, 260 redémarrages (≈ 22 h à 5 min de backoff).
  • Même journal que #31 et #49 : 
    Error: unable to rename (/export/.minio.sys/tmp -> /export/.minio.sys/tmp-old/<uuid>) drive is faulty
FATAL Unable to initialize backend: drive is faulty
  • Côté kadans-api : Head "http://minio.tools.svc.cluster.local:9000/…": dial tcp 10.43.120.205:9000: connect: connection refused (Endpoints minio vides). Aucun envoi ne pouvait aboutir.
  • Longhorn : volume pvc-ebb2605f-… attached / healthy, 3 répliques running — il dit sain, comme les deux fois précédentes.

Chronologie (mesurée)

  • 2026-09-23 10:28:18 UTC — kadans-jobs : store redis : lecture en masse impossible : … i/o timeout (à-coup réseau).
  • 2026-09-23 11:01:09 et 11:04:47 UTC — instance-manager de pi3, moteur du volume : R/W Timeout. No response received in 8s → Setting replica tcp://10.42.0.11:… to ERR (deux fois en 4 min).
  • ⇒ écritures en échec → ext4 abandonne son journal → lecture seule jusqu'au démontage. Un redémarrage du conteneur ne démonte pas le volume : le CrashLoop ne peut pas guérir seul.

Réparation (sans perte, remède de #31)

  • 09:01:56 UTC kubectl --context default -n tools scale deploy/minio --replicas=0 ; ArgoCD (selfHeal) a remis replicas=1 → pod neuf minio-646d87c9bc-46wmk sur pi3, montage neuf.
  • Vérifié : /minio/health/live 200, /minio/health/cluster 200, fichier écrit/relu/effacé dans /export/.minio.sys/tmp → écriture OK. Dernier connection refused côté API : 09:02:17. Aucune donnée supprimée.

Ce qui reste ouvert (cause première non traitée, 3ᵉ fois)

  1. Sortir MinIO de pi2 n'a pas suffi : l'à-coup a frappé le moteur sur pi3 (la réplique perdue est 10.42.0.11). La cause est le délai de 8 s entre moteur et répliques sous charge/réseau, pas un nœud.
  2. Rien n'alerte : 22 h de panne découvertes par le fondateur au téléphone. Une sonde de liveness ne suffit pas (elle redémarre le conteneur, pas le montage). Pistes : alerte sur kube_pod_container_status_restarts_total / CrashLoopBackOff du namespace tools ; ou un garde qui supprime le pod (pas le conteneur) quand le journal dit drive is faulty.
  3. Migration SeaweedFS (#48) : même volume Longhorn → même exposition ; à peser.

Précédents : #31 (29/08, pi2), #49 (14/09, pi2).

🤖 Generated with Claude Code

## Constat (2026-09-24, signalé par le fondateur : « l'upload de vidéos depuis mon téléphone semble bloqué ») - Pod `tools/minio-646d87c9bc-hscwt` sur **pi3** : `0/1 CrashLoopBackOff`, **260 redémarrages** (≈ 22 h à 5 min de backoff). - Même journal que #31 et #49 : ``` Error: unable to rename (/export/.minio.sys/tmp -> /export/.minio.sys/tmp-old/<uuid>) drive is faulty FATAL Unable to initialize backend: drive is faulty ``` - Côté kadans-api : `Head "http://minio.tools.svc.cluster.local:9000/…": dial tcp 10.43.120.205:9000: connect: connection refused` (Endpoints `minio` vides). Aucun envoi ne pouvait aboutir. - Longhorn : volume `pvc-ebb2605f-…` `attached / healthy`, 3 répliques `running` — **il dit sain, comme les deux fois précédentes**. ## Chronologie (mesurée) - 2026-09-23 **10:28:18 UTC** — kadans-jobs : `store redis : lecture en masse impossible : … i/o timeout` (à-coup réseau). - 2026-09-23 **11:01:09 et 11:04:47 UTC** — instance-manager de pi3, moteur du volume : `R/W Timeout. No response received in 8s` → `Setting replica tcp://10.42.0.11:… to ERR` (deux fois en 4 min). - ⇒ écritures en échec → ext4 abandonne son journal → lecture seule jusqu'au démontage. Un redémarrage du **conteneur** ne démonte pas le volume : le CrashLoop ne peut pas guérir seul. ## Réparation (sans perte, remède de #31) - 09:01:56 UTC `kubectl --context default -n tools scale deploy/minio --replicas=0` ; ArgoCD (selfHeal) a remis `replicas=1` → pod neuf `minio-646d87c9bc-46wmk` sur pi3, montage neuf. - Vérifié : `/minio/health/live` **200**, `/minio/health/cluster` **200**, fichier écrit/relu/effacé dans `/export/.minio.sys/tmp` → **écriture OK**. Dernier `connection refused` côté API : 09:02:17. Aucune donnée supprimée. ## Ce qui reste ouvert (cause première non traitée, 3ᵉ fois) 1. **Sortir MinIO de pi2 n'a pas suffi** : l'à-coup a frappé le moteur sur pi3 (la réplique perdue est `10.42.0.11`). La cause est le délai de 8 s entre moteur et répliques sous charge/réseau, pas un nœud. 2. **Rien n'alerte** : 22 h de panne découvertes par le fondateur au téléphone. Une sonde de liveness ne suffit pas (elle redémarre le conteneur, pas le montage). Pistes : alerte sur `kube_pod_container_status_restarts_total` / CrashLoopBackOff du namespace `tools` ; ou un garde qui **supprime le pod** (pas le conteneur) quand le journal dit `drive is faulty`. 3. Migration SeaweedFS (#48) : même volume Longhorn → même exposition ; à peser. Précédents : #31 (29/08, pi2), #49 (14/09, pi2). 🤖 Generated with [Claude Code](https://claude.com/claude-code)
arcodange commented 2026-09-25 18:26:41 +02:00
Author
Owner
Copy Link
Copy Source

Nouvelle récidive le 2026-09-25, réparée à 18 h 22 (accord du fondateur)

Symptôme

  • tools/minio en CrashLoopBackOff : unable to rename .minio.sys/tmp … drive is faulty.
  • s3.arcodange.fr rendait 503 depuis environ 04 h 26.
  • Le noyau de pi3 signalait critical medium error, dev sdd (le volume Longhorn pvc-ebb2605f…), alors que Longhorn affichait healthy avec ses 3 répliques running.

Ce qui n'a PAS suffi

  • scale --replicas=0 seul. ArgoCD (selfHeal, sur minio comme sur l'app parente tools) a remis 1 réplique en quelques secondes : le volume n'a jamais été détaché, et le nouveau pod a replanté pareil.

Ce qui a marché

  1. Un instantané Longhorn d'abord : minio-avant-detachement-2026-09-25, prêt en 5 s.
  2. L'auto-synchronisation d'ArgoCD retirée sur tools puis sur minio, et scale --replicas=0.
  3. Le volume est passé en detaching, puis a été rattaché avec un montage neuf. Le passage de fsck au montage est la voie que décrit le diagnostic de la session voisine ; je ne l'ai pas vu dans un journal.
  4. Relevé : pod 1/1 Running, /minio/health/live et /minio/health/ready à 200, aucune ligne faulty ni error dans le journal.
  5. La politique de synchronisation des deux apps est revenue à {prune: true, selfHeal: true}, comme avant.

Ce qui reste ouvert (cette issue)

  • Aucune alerte n'a prévenu : la panne a duré environ 14 h.
  • La cause première est une erreur d'E/S du moteur Longhorn pendant un incident réseau du homelab.
  • Le fondateur a répondu à la session voisine : « No need for replicas for homelab ». Un agent évalue une autre classe de stockage pour MinIO (local-path, ou Longhorn à 1 réplique).
## Nouvelle récidive le 2026-09-25, réparée à 18 h 22 (accord du fondateur) **Symptôme** - `tools/minio` en CrashLoopBackOff : `unable to rename .minio.sys/tmp … drive is faulty`. - `s3.arcodange.fr` rendait 503 depuis environ 04 h 26. - Le noyau de pi3 signalait `critical medium error, dev sdd` (le volume Longhorn `pvc-ebb2605f…`), alors que Longhorn affichait `healthy` avec ses 3 répliques `running`. **Ce qui n'a PAS suffi** - `scale --replicas=0` seul. ArgoCD (selfHeal, sur `minio` comme sur l'app parente `tools`) a remis 1 réplique en quelques secondes : le volume n'a jamais été détaché, et le nouveau pod a replanté pareil. **Ce qui a marché** 1. Un instantané Longhorn d'abord : `minio-avant-detachement-2026-09-25`, prêt en 5 s. 2. L'auto-synchronisation d'ArgoCD retirée sur `tools` puis sur `minio`, et `scale --replicas=0`. 3. Le volume est passé en `detaching`, puis a été rattaché avec un montage neuf. Le passage de `fsck` au montage est la voie que décrit le diagnostic de la session voisine ; je ne l'ai pas vu dans un journal. 4. Relevé : pod `1/1 Running`, `/minio/health/live` et `/minio/health/ready` à 200, aucune ligne `faulty` ni `error` dans le journal. 5. La politique de synchronisation des deux apps est revenue à `{prune: true, selfHeal: true}`, comme avant. **Ce qui reste ouvert (cette issue)** - Aucune alerte n'a prévenu : la panne a duré environ 14 h. - La cause première est une erreur d'E/S du moteur Longhorn pendant un incident réseau du homelab. - Le fondateur a répondu à la session voisine : « No need for replicas for homelab ». Un agent évalue une autre classe de stockage pour MinIO (local-path, ou Longhorn à 1 réplique).
arcodange commented 2026-09-26 17:58:26 +02:00
Author
Owner
Copy Link
Copy Source

Bascule de MinIO sur le disque externe de pi1 — bilan du 2026-09-26

Fait : tools#60 (→ 865b8254), fusionné à 11 h 05 ; MinIO prêt à 11 h 12 sur le PV local minio-disque-externe (pi1:/mnt/arcodange/minio, Retain, Prune=false). .lab, kadans.arcodange.fr et s3.arcodange.fr/minio/health/live rendent 200 (relevé 17 h 56).

⚠ Ce qui n'a PAS marché

  • Copie 1 (Job minio-vers-disque-externe-1) : set -eu, rsync sans tuyau → Completed = rsync à 0. Digne de foi.
  • Copie 2 (le rattrapage) : « Complete » MENTEUR. rsync … | grep | tail sans pipefail : le Job a pris le code de tail. rsync a rendu 23 (I/O error (5) sur /source/kadans-videos, /source/.minio.sys, lost+found) et a transféré 0 octet. Erreur de script de ma part.
  • Conséquence : ce que l'ancien MinIO a reçu entre la copie 1 (≈ 10 h 48) et la bascule (11 h 05) n'est pas sur le disque externe, et l'ancien volume Longhorn pvc-ebb2605f (le retour arrière) est illisible aujourd'hui : une seule réplique (pi2, stopped), détaché. Instantanés existants : fadbd8e4… (25/09 02:30 UTC) et minio-avant-detachement-2026-09-25 — tous deux ANTÉRIEURS à la fenêtre.

Effet de bord de la fusion : toutes les apps ArgoCD suivant main, la LAPI CrowdSec a replanté sur pi1, où Longhorn refusait tout attachement (engineimages ei-b4bcf0a5 : nodeDeploymentMap.pi1=false figé depuis 00:06Z, pod du moteur pourtant prêt) → 403 sur tout kadans.arcodange.fr et s3.arcodange.fr de ~11 h à 17 h 56. Recréer le pod du moteur sur pi1 puis redémarrer le manager propriétaire (pi3), avec l'accord du fondateur, n'a pas réécrit la carte ; elle était à true à 17 h 42 — lue dans la même seconde qu'une annotation de réveil posée après 5 h 40 d'attente, donc cause et remède non établis. La LAPI est finalement repartie sur pi3.

Reste à décider (fondateur) : que faire de la fenêtre non couverte et du volume pvc-ebb2605f.

## Bascule de MinIO sur le disque externe de pi1 — bilan du 2026-09-26 **Fait** : tools#60 (→ 865b8254), fusionné à 11 h 05 ; MinIO prêt à 11 h 12 sur le PV local `minio-disque-externe` (pi1:/mnt/arcodange/minio, `Retain`, `Prune=false`). `.lab`, `kadans.arcodange.fr` et `s3.arcodange.fr/minio/health/live` rendent 200 (relevé 17 h 56). **⚠ Ce qui n'a PAS marché** - **Copie 1** (Job `minio-vers-disque-externe-1`) : `set -eu`, rsync sans tuyau → `Completed` = rsync à 0. Digne de foi. - **Copie 2 (le rattrapage) : « Complete » MENTEUR.** `rsync … | grep | tail` sans `pipefail` : le Job a pris le code de `tail`. rsync a rendu **23** (`I/O error (5)` sur `/source/kadans-videos`, `/source/.minio.sys`, `lost+found`) et a transféré **0 octet**. Erreur de script de ma part. - Conséquence : **ce que l'ancien MinIO a reçu entre la copie 1 (≈ 10 h 48) et la bascule (11 h 05) n'est pas sur le disque externe**, et l'ancien volume Longhorn `pvc-ebb2605f` (le retour arrière) est illisible aujourd'hui : **une seule réplique (pi2, stopped)**, détaché. Instantanés existants : `fadbd8e4…` (25/09 02:30 UTC) et `minio-avant-detachement-2026-09-25` — tous deux ANTÉRIEURS à la fenêtre. **Effet de bord de la fusion** : toutes les apps ArgoCD suivant `main`, la LAPI CrowdSec a replanté sur pi1, où Longhorn refusait tout attachement (`engineimages ei-b4bcf0a5` : `nodeDeploymentMap.pi1=false` figé depuis 00:06Z, pod du moteur pourtant prêt) → **403 sur tout `kadans.arcodange.fr` et `s3.arcodange.fr` de ~11 h à 17 h 56**. Recréer le pod du moteur sur pi1 puis redémarrer le manager propriétaire (pi3), avec l'accord du fondateur, n'a pas réécrit la carte ; elle était à `true` à 17 h 42 — lue dans la même seconde qu'une annotation de réveil posée après 5 h 40 d'attente, donc **cause et remède non établis**. La LAPI est finalement repartie sur pi3. **Reste à décider (fondateur)** : que faire de la fenêtre non couverte et du volume `pvc-ebb2605f`.
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#58