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

Mémoire de pi2 : 2,5 Gi pris par un démon de bureau (gvfs-udisks2) qui fuit depuis 154 jours — relevé et options chiffrées, rien d'appliqué #52

New Issue
Open
opened 2026-09-15 12:01:44 +02:00 by arcodange · 8 comments
arcodange commented 2026-09-15 12:01:44 +02:00
Owner
Copy Link
Copy Source

Pourquoi

Le 14/09, pi2 était saturé en mémoire, sans swap. Le moteur Longhorn y a dépassé son délai de 8 s, et ext4 a abandonné son journal sur quatre volumes qui ont une réplique ou un moteur sur pi2 : MinIO, loki, url-shortener et prometheus-server. Détail dans tools#49.

Un cinquième volume, ClickHouse (tools#53), a le journal abandonné depuis le 04/09, sur pi3. Sa cause n'est pas établie.

Consigne du fondateur (2026-09-15) : « Un relevé et un plan, rien d'appliqué. »

Relevé (2026-09-15, 09:58–10:00Z, lecture seule, --context=default)

Nœuds

kubectl top capacité allocatable MemAvailable (physique) swap
pi1 74 % (5 993 Mi) 7,86 Gi 7,86 Gi 2 620 Mi non
pi2 106–111 % (6 136–6 427 Mi) 7,64 Gi 5,64 Gi 1 577 Mi non
pi3 66–69 % 7,86 Gi 7,86 Gi 2 906 Mi non

⚠ Le « 108 % » de pi2 est relatif à l'allocatable, pas à la mémoire physique.

  • pi2 est le seul nœud avec --kubelet-arg=system-reserved=cpu=2,memory=2Gi (dans k3s-agent.service).
  • Physiquement, il reste environ 1,5 Gi disponibles sur 7,6 Gi, contre 2,6 à 2,9 Gi sur les deux autres.
  • earlyoom tourne et tue déjà : argocd-application-controller le 13/09 et le 15/09, ffmpeg (626 Mi) le 15/09 à 06:53.
  • Autre signe de saturation : à 10:00Z, kubectl logs d'un pod de pi2 a échoué sur TLS handshake timeout vers le kubelet.

Ce qui pèse sur pi2

1. ⚠⚠ gvfs-udisks2-volume-monitor (utilisateur pi, session de bureau) : 2 608 Mi RSS, 2,54 Gi PSS, démarré il y a 154 jours.

  • Le même processus pèse 9 Mi sur pi1 et 7 Mi sur pi3.
  • C'est le premier consommateur du nœud, un tiers de sa RAM, et il n'a rien à voir avec Kubernetes.
  • Hypothèse, non prouvée : il surveille les périphériques bloc et fuit à chaque attachement iSCSI de Longhorn. pi2 en compte 12 depuis le 01/09, contre 2 sur pi1 et 6 sur pi3.
  • Les trois Pi font tourner un bureau (lightdm et wayvnc actifs).

2. Conteneurs Docker hors Kubernetes : la forge elle-même.

  • gitea : 607 Mi, limite 1,5 Gi.
  • postgres : 270 Mi, limite 1 Gi.

3. Pods (kubectl top, triés). Les pods sans limite sont marqués « aucune ».

Pod Mesuré Requête / limite
longhorn-system/instance-manager (pi2) 571 Mi aucune
argocd/argocd-application-controller-0 247 Mi aucune (tué 2× par earlyoom)
longhorn-system/longhorn-manager 206 Mi aucune
tools/loki-0 200 Mi 256 / 512 Mi
argocd/argocd-repo-server 188 Mi aucune (252 redémarrages)
tools/alloy 99 Mi 160 / 448 Mi
argocd/argocd-image-updater 60 Mi aucune (285 redémarrages)
vault-secrets-operator 53 Mi 128 / 256 Mi
les 17 autres < 45 Mi chacun
  • Somme des pods de pi2 : environ 2,0 Gi.
  • Requêtes allouées : 902 Mi (15 %). Limites : 2 240 Mi (38 %).

4. Longhorn.

  • 17 répliques en marche sur chaque nœud : 3 répliques par volume, anti-affinité stricte (replica-soft-anti-affinity=false). Toute réplique de pi2 est donc « la troisième » d'un volume.
  • Moteurs (volumes attachés) après les bascules du jour : pi1 = 6, pi2 = 1 (loki), pi3 = 10.
  • instance-manager : pi1 762 Mi, pi2 570 Mi, pi3 786 Mi.
  • engine-replica-timeout est au défaut (8 s). C'est le délai dépassé le 14/09.
  • Deux volumes orphelins ont été détachés ce matin (tools#49). Gain mesuré sur pi2 : environ 107 Mi de RSS de processus Longhorn libérés, mais seulement +72 Mi de MemAvailable, soit l'ordre du bruit.

Options chiffrées (aucune appliquée)

# Option Gain mémoire pi2 Prix / risque
A Redémarrer gvfs-udisks2-volume-monitor (service utilisateur de pi) ≈ 2,5 Gi, immédiat Quasi nul pour le cluster (aucun pod n'en dépend). La fuite reviendra si la cause est l'attachement iSCSI.
A' Le masquer sur les trois Pi, ou désactiver la session de bureau (lightdm, wayvnc) ≈ 2,5 Gi durable, plus quelques centaines de Mi de bureau On perd le montage automatique USB et l'accès VNC au bureau. À vérifier : que rien ne dépend de VNC pour l'administration.
B Limites mémoire sur argocd-application-controller et repo-server 0 (la consommation ne baisse pas) Déplace l'OOM dans le cgroup : ArgoCD redémarre au lieu de faire tuer un voisin. Le repo-server a déjà 252 redémarrages.
C Sortir ArgoCD de pi2 (affinité dans son chart) ≈ 550 Mi Charge reportée sur pi1 ou pi3. pi3 porte déjà 10 moteurs Longhorn (concentration : une panne de pi3 touche MinIO, Prometheus, Vault, ClickHouse…).
D Swap (zram 1–2 Gi, ou fichier sur le SSD USB sda) 1–2 Gi de marge ⚠ Ralentir au lieu de tuer, c'est exactement ce qui a tué ext4 : une page lente sous le moteur Longhorn peut refaire dépasser les 8 s. zram coûte du CPU (pi2 est déjà à 110–190 %). Il faut aussi failSwapOn=false sur kubelet. Fichier sur la carte SD : usure, et / est à 92 %.
E Retirer les répliques Longhorn de pi2 (allowScheduling=false + éviction, avec 2 répliques par volume) ≈ 300–400 Mi (une part d'instance-manager) Redondance 3 → 2 sur tous les volumes. Reconstruction lourde en E/S pendant l'éviction. Irréversible sans re-reconstruction.
F Monter engine-replica-timeout de 8 s à 15–30 s 0 Ne traite pas la mémoire, mais retire le mécanisme exact de l'incident (medium error, puis journal abandonné). En contrepartie, des écritures restent bloquées plus longtemps en silence.
G Déplacer Gitea et Postgres (Docker hôte) hors de pi2 ≈ 880 Mi Cher : c'est la forge (SSH 192.168.1.202:2222, remotes de tous les dépôts, runners). Interruption et changement d'adresse.
H Retirer system-reserved memory=2Gi de pi2, ou l'aligner sur les autres nœuds 0 (seul le % affiché change) Kubernetes placerait plus de pods sur un nœud qui n'a pas la mémoire. À ne faire qu'après A'.

Recommandation (à arbitrer) :

  • A tout de suite, puis A'. Un seul geste hors du cluster rend un tiers de la RAM de pi2, sans toucher aux données.
  • F en complément : c'est le seul levier qui traite le mécanisme de l'incident et pas seulement le terrain.
  • On re-mesure ensuite avant toute option B à H.

Mesures reproductibles

kubectl --context=default top nodes
ssh pi2 'ps -eo rss,comm --sort=-rss | head; grep MemAvailable /proc/meminfo'
ssh pi2 'grep Pss /proc/$(pgrep -f gvfs-udisks2-volume-monitor)/smaps_rollup'

Refs arcodange-org/tools#49 · arcodange-org/tools#53

🤖 Generated with Claude Code

## Pourquoi Le 14/09, pi2 était saturé en mémoire, sans swap. Le moteur Longhorn y a dépassé son délai de 8 s, et ext4 a abandonné son journal sur **quatre** volumes qui ont une réplique ou un moteur sur pi2 : MinIO, loki, url-shortener et prometheus-server. Détail dans tools#49. Un cinquième volume, ClickHouse (tools#53), a le journal abandonné depuis le **04/09**, sur pi3. Sa cause n'est **pas établie**. Consigne du fondateur (2026-09-15) : **« Un relevé et un plan, rien d'appliqué. »** ## Relevé (2026-09-15, 09:58–10:00Z, lecture seule, `--context=default`) ### Nœuds | | `kubectl top` | capacité | allocatable | `MemAvailable` (physique) | swap | |---|---|---|---|---|---| | pi1 | 74 % (5 993 Mi) | 7,86 Gi | 7,86 Gi | 2 620 Mi | non | | **pi2** | **106–111 %** (6 136–6 427 Mi) | 7,64 Gi | **5,64 Gi** | **1 577 Mi** | **non** | | pi3 | 66–69 % | 7,86 Gi | 7,86 Gi | 2 906 Mi | non | ⚠ **Le « 108 % » de pi2 est relatif à l'allocatable, pas à la mémoire physique.** - pi2 est le seul nœud avec `--kubelet-arg=system-reserved=cpu=2,memory=2Gi` (dans `k3s-agent.service`). - Physiquement, il reste environ 1,5 Gi disponibles sur 7,6 Gi, contre 2,6 à 2,9 Gi sur les deux autres. - **earlyoom** tourne et tue déjà : `argocd-application-controller` le 13/09 et le 15/09, `ffmpeg` (626 Mi) le 15/09 à 06:53. - Autre signe de saturation : à 10:00Z, `kubectl logs` d'un pod de pi2 a échoué sur `TLS handshake timeout` vers le kubelet. ### Ce qui pèse sur pi2 **1. ⚠⚠ `gvfs-udisks2-volume-monitor` (utilisateur `pi`, session de bureau) : 2 608 Mi RSS, 2,54 Gi PSS, démarré il y a 154 jours.** - Le même processus pèse **9 Mi sur pi1 et 7 Mi sur pi3**. - C'est **le premier consommateur du nœud, un tiers de sa RAM**, et il n'a rien à voir avec Kubernetes. - Hypothèse, non prouvée : il surveille les périphériques bloc et fuit à chaque attachement iSCSI de Longhorn. pi2 en compte 12 depuis le 01/09, contre 2 sur pi1 et 6 sur pi3. - Les trois Pi font tourner un bureau (`lightdm` et `wayvnc` actifs). **2. Conteneurs Docker hors Kubernetes : la forge elle-même.** - `gitea` : 607 Mi, limite 1,5 Gi. - `postgres` : 270 Mi, limite 1 Gi. **3. Pods (`kubectl top`, triés).** Les pods sans limite sont marqués « aucune ». | Pod | Mesuré | Requête / limite | |---|---|---| | `longhorn-system/instance-manager` (pi2) | 571 Mi | aucune | | `argocd/argocd-application-controller-0` | 247 Mi | aucune (tué 2× par earlyoom) | | `longhorn-system/longhorn-manager` | 206 Mi | aucune | | `tools/loki-0` | 200 Mi | 256 / 512 Mi | | `argocd/argocd-repo-server` | 188 Mi | aucune (252 redémarrages) | | `tools/alloy` | 99 Mi | 160 / 448 Mi | | `argocd/argocd-image-updater` | 60 Mi | aucune (285 redémarrages) | | `vault-secrets-operator` | 53 Mi | 128 / 256 Mi | | les 17 autres | < 45 Mi chacun | | - Somme des pods de pi2 : environ 2,0 Gi. - Requêtes allouées : 902 Mi (15 %). Limites : 2 240 Mi (38 %). **4. Longhorn.** - **17 répliques en marche sur chaque nœud** : 3 répliques par volume, anti-affinité stricte (`replica-soft-anti-affinity=false`). Toute réplique de pi2 est donc « la troisième » d'un volume. - Moteurs (volumes attachés) après les bascules du jour : **pi1 = 6, pi2 = 1 (loki), pi3 = 10**. - `instance-manager` : pi1 762 Mi, pi2 570 Mi, pi3 786 Mi. - `engine-replica-timeout` est au défaut (8 s). C'est le délai dépassé le 14/09. - Deux volumes orphelins ont été **détachés** ce matin (tools#49). Gain mesuré sur pi2 : environ 107 Mi de RSS de processus Longhorn libérés, mais seulement +72 Mi de `MemAvailable`, soit l'ordre du bruit. ## Options chiffrées (aucune appliquée) | # | Option | Gain mémoire pi2 | Prix / risque | |---|---|---|---| | **A** | **Redémarrer `gvfs-udisks2-volume-monitor`** (service utilisateur de `pi`) | **≈ 2,5 Gi, immédiat** | Quasi nul pour le cluster (aucun pod n'en dépend). La fuite reviendra si la cause est l'attachement iSCSI. | | **A'** | **Le masquer sur les trois Pi**, ou désactiver la session de bureau (`lightdm`, `wayvnc`) | ≈ 2,5 Gi durable, plus quelques centaines de Mi de bureau | On perd le montage automatique USB et l'accès VNC au bureau. À vérifier : que rien ne dépend de VNC pour l'administration. | | B | Limites mémoire sur `argocd-application-controller` et `repo-server` | 0 (la consommation ne baisse pas) | Déplace l'OOM dans le cgroup : ArgoCD redémarre au lieu de faire tuer un voisin. Le repo-server a déjà 252 redémarrages. | | C | Sortir ArgoCD de pi2 (affinité dans son chart) | ≈ 550 Mi | Charge reportée sur pi1 ou pi3. pi3 porte déjà 10 moteurs Longhorn (concentration : une panne de pi3 touche MinIO, Prometheus, Vault, ClickHouse…). | | D | Swap (zram 1–2 Gi, ou fichier sur le SSD USB `sda`) | 1–2 Gi de marge | ⚠ **Ralentir au lieu de tuer, c'est exactement ce qui a tué ext4** : une page lente sous le moteur Longhorn peut refaire dépasser les 8 s. zram coûte du CPU (pi2 est déjà à 110–190 %). Il faut aussi `failSwapOn=false` sur kubelet. Fichier sur la carte SD : usure, et `/` est à 92 %. | | E | Retirer les répliques Longhorn de pi2 (`allowScheduling=false` + éviction, avec 2 répliques par volume) | ≈ 300–400 Mi (une part d'`instance-manager`) | Redondance 3 → 2 sur tous les volumes. Reconstruction lourde en E/S pendant l'éviction. Irréversible sans re-reconstruction. | | F | Monter `engine-replica-timeout` de 8 s à 15–30 s | 0 | Ne traite pas la mémoire, mais **retire le mécanisme exact de l'incident** (medium error, puis journal abandonné). En contrepartie, des écritures restent bloquées plus longtemps en silence. | | G | Déplacer Gitea et Postgres (Docker hôte) hors de pi2 | ≈ 880 Mi | Cher : c'est la forge (SSH `192.168.1.202:2222`, remotes de tous les dépôts, runners). Interruption et changement d'adresse. | | H | Retirer `system-reserved memory=2Gi` de pi2, ou l'aligner sur les autres nœuds | 0 (seul le % affiché change) | Kubernetes placerait **plus** de pods sur un nœud qui n'a pas la mémoire. À ne faire qu'après A'. | **Recommandation (à arbitrer)** : - **A tout de suite, puis A'**. Un seul geste hors du cluster rend un tiers de la RAM de pi2, sans toucher aux données. - **F** en complément : c'est le seul levier qui traite le mécanisme de l'incident et pas seulement le terrain. - On re-mesure ensuite avant toute option B à H. ## Mesures reproductibles ``` kubectl --context=default top nodes ssh pi2 'ps -eo rss,comm --sort=-rss | head; grep MemAvailable /proc/meminfo' ssh pi2 'grep Pss /proc/$(pgrep -f gvfs-udisks2-volume-monitor)/smaps_rollup' ``` Refs arcodange-org/tools#49 · arcodange-org/tools#53 🤖 Generated with [Claude Code](https://claude.com/claude-code)
arcodange commented 2026-09-15 12:27:18 +02:00
Author
Owner
Copy Link
Copy Source

Option A puis A' appliquées (12:28) : gvfs-udisks2 redémarré sur pi2, puis masqué sur les 3 Pi

Accord du fondateur : « Le redémarrer, puis le désactiver sur les 3 Pi ».

Qui le lance (relevé)

  • Unité utilisateur static : /usr/lib/systemd/user/gvfs-udisks2-volume-monitor.service (Slice=session.slice, PartOf=graphical-session.target).
  • Processus fils du systemd --user de pi (sessions seat0 / tty1 du bureau). Paquet gvfs-daemons.
  • Activée par D-Bus : org.gtk.vfs.UDisks2VolumeMonitor.service porte SystemdService=gvfs-udisks2-volume-monitor.service.
  • Le bus de session tourne en dbus-daemon --session --systemd-activation.

1. Redémarrage sur pi2 (10:17:21Z, systemctl --user restart, code 0)

avant après
free -m available 1 728 Mi 4 340 Mi (+2 612)
free -m used 6 092 Mi 3 480 Mi
kubectl --context=default top node pi2 6 195 Mi (107 %) 3 754 Mi (65 %)
PSS du processus 2,54 Gi 7,6 Mi

2. Désactivation durable : PR arcodange-org/factory#58, fusionnée (777709c)

La configuration des Pi vit dans factory/ansible (earlyoom, k3s…) : le changement passe donc par là, pas à la main.

  • Playbook system/gvfs_udisks2.yml, importé par system.yml après earlyoom. Il :
    • pose systemctl --global mask ;
    • arrête l'instance de la session ;
    • relit que l'unité est masked et que pgrep rend 1.
  • Choix : masquer, pas désinstaller. gvfs-daemons porte tout gvfs, dont dépend le bureau. Le masque est ciblé et réversible, et il suffit puisque le bus active le service par systemd.
  • Application (10:26Z, depuis main, --context=default pour le mot de passe vault) : code 0 ; pi1, pi2 et pi3 en ok=7 changed=2 failed=0 ; les trois assertions sont vertes.
  • Rejeu : code 0, changed=0 sur les trois nœuds (idempotent).
  • Témoin que le masque mord, sur pi2 : un réveil par le bus (gdbus call … org.gtk.vfs.UDisks2VolumeMonitor … IsSupported) rend GDBus.Error:org.freedesktop.systemd1.UnitMasked, code 1, et pgrep rend 1 ensuite. /etc/systemd/user/gvfs-udisks2-volume-monitor.service -> /dev/null.
  • Aucun nœud redémarré.

Mémoire à 10:28Z

top node free available
pi1 6 447 Mi (80 %) 1 813 Mi
pi2 3 771 Mi (65 %) 4 243 Mi
pi3 4 692 Mi (58 %) 3 775 Mi

⚠ pi1 remonte : il avait 2 620 Mi disponibles à 10:00Z, il en a 1 813. ClickHouse (≈ 530 Mi) y a été déplacé à 10:20Z (tools#53), et des reconstructions de répliques ont eu lieu. Il est désormais le nœud le plus chargé : à surveiller.

Suite : le délai Longhorn (option F) dans un prochain commentaire.

🤖 Generated with Claude Code

## Option A puis A' appliquées (12:28) : gvfs-udisks2 redémarré sur pi2, puis masqué sur les 3 Pi Accord du fondateur : « Le redémarrer, puis le désactiver sur les 3 Pi ». ### Qui le lance (relevé) - Unité utilisateur **`static`** : `/usr/lib/systemd/user/gvfs-udisks2-volume-monitor.service` (`Slice=session.slice`, `PartOf=graphical-session.target`). - Processus fils du `systemd --user` de `pi` (sessions `seat0` / `tty1` du bureau). Paquet `gvfs-daemons`. - **Activée par D-Bus** : `org.gtk.vfs.UDisks2VolumeMonitor.service` porte `SystemdService=gvfs-udisks2-volume-monitor.service`. - Le bus de session tourne en `dbus-daemon --session --systemd-activation`. ### 1. Redémarrage sur pi2 (10:17:21Z, `systemctl --user restart`, code 0) | | avant | après | |---|---|---| | `free -m` available | 1 728 Mi | **4 340 Mi** (+2 612) | | `free -m` used | 6 092 Mi | 3 480 Mi | | `kubectl --context=default top node pi2` | 6 195 Mi (107 %) | **3 754 Mi (65 %)** | | PSS du processus | 2,54 Gi | 7,6 Mi | ### 2. Désactivation durable : **PR arcodange-org/factory#58**, fusionnée (`777709c`) La configuration des Pi vit dans `factory/ansible` (earlyoom, k3s…) : le changement passe donc par là, pas à la main. - **Playbook `system/gvfs_udisks2.yml`**, importé par `system.yml` après earlyoom. Il : - pose `systemctl --global mask` ; - arrête l'instance de la session ; - relit que l'unité est `masked` et que `pgrep` rend 1. - **Choix : masquer, pas désinstaller.** `gvfs-daemons` porte tout gvfs, dont dépend le bureau. Le masque est ciblé et réversible, et il suffit puisque le bus active le service par systemd. - **Application** (10:26Z, depuis `main`, `--context=default` pour le mot de passe vault) : **code 0** ; `pi1`, `pi2` et `pi3` en `ok=7 changed=2 failed=0` ; les trois assertions sont vertes. - **Rejeu** : code 0, `changed=0` sur les trois nœuds (idempotent). - **Témoin que le masque mord**, sur pi2 : un réveil par le bus (`gdbus call … org.gtk.vfs.UDisks2VolumeMonitor … IsSupported`) rend `GDBus.Error:org.freedesktop.systemd1.UnitMasked`, code 1, et `pgrep` rend 1 ensuite. `/etc/systemd/user/gvfs-udisks2-volume-monitor.service -> /dev/null`. - Aucun nœud redémarré. ### Mémoire à 10:28Z | | `top node` | `free` available | |---|---|---| | pi1 | 6 447 Mi (80 %) | 1 813 Mi | | pi2 | **3 771 Mi (65 %)** | **4 243 Mi** | | pi3 | 4 692 Mi (58 %) | 3 775 Mi | ⚠ **pi1 remonte** : il avait 2 620 Mi disponibles à 10:00Z, il en a 1 813. ClickHouse (≈ 530 Mi) y a été déplacé à 10:20Z (tools#53), et des reconstructions de répliques ont eu lieu. Il est désormais **le nœud le plus chargé** : à surveiller. Suite : le délai Longhorn (option F) dans un prochain commentaire. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
arcodange commented 2026-09-15 12:32:42 +02:00
Author
Owner
Copy Link
Copy Source

Option F appliquée (12:33) : délai moteur→réplica Longhorn de 8 à 20 s

Accord du fondateur : « Oui, après avoir soulagé pi2 ». pi2 est à 65 % depuis 10:17Z.

Le réglage

Réglage engine-replica-timeout, valeur Helm defaultSettings.engineReplicaTimeout. Doc Longhorn v1.9.1, Settings Reference :

« The time in seconds a v1 engine will wait for a response from a replica before marking it as failed. Values between 8 and 30 are allowed. »
« A V1 engine marks the last active replica as failed only after twice the configured number of seconds (timeout value x 2) have passed. »

Valeur retenue : 20 s.

  • Le dernier réplica est déclaré mort à 40 s.
  • Cela reste sous le délai SCSI du noyau de 60 s, relevé sur tous les disques Longhorn des 3 Pi.
  • À 30 s, on atteindrait 60 s : ce serait le noyau qui abandonnerait la commande.

Le prix

  • Une vraie panne de réplica est constatée en 20 s au lieu de 8 (40 s au lieu de 16 pour le dernier), et les écritures du volume sont suspendues pendant ce temps.
  • ⚠ Le réglage ne vaut que pour les moteurs démarrés après : la valeur est passée en drapeau --engine-replica-timeout au lancement (relevé : 8 sur les moteurs en marche). Les 17 volumes attachés gardent 8 s jusqu'à leur prochain rattachement.
  • Aucun rattachement n'a été forcé.

La voie

Longhorn est installé par le HelmChart k3s que pose factory/ansible/…/system/k3s_config.yml. Le changement passe donc par PR arcodange-org/factory#59, fusionnée (b63aefa).

  • Avant application :
    • helm template v1.9.1 avant/après : une seule ligne diffère, dans la ConfigMap longhorn-default-setting, et aucun pod n'est recréé ;
    • la release en place est identique au rendu « avant » ;
    • --check --diff : un seul fichier modifié.
  • La tâche a reçu le tag longhorn.
  • ⚠ Piège relevé : sans tag, ce playbook supprime le Deployment traefik dans le contexte kubectl COURANT, qui peut être un autre cluster.
  • Application (10:30:54Z) :
    • ansible-playbook … k3s_config.yml --tags longhorn : code 0, seul setup longhorn est changed sur pi1 ;
    • release Helm longhorn-install passée de la révision 1 à la révision 2 (Upgrade complete, 10:31:31Z), job helm-install-longhorn-install terminé à 10:32:15Z.
  • Vérifié :
    • la ConfigMap porte engine-replica-timeout: 20 ;
    • settings.longhorn.io/engine-replica-timeout = 20 (valeur vivante, relue à 10:32:16Z) ;
    • aucun pod Longhorn recréé ni en erreur ;
    • 17 volumes attached healthy, 2 detached (les orphelins).

🤖 Generated with Claude Code

## Option F appliquée (12:33) : délai moteur→réplica Longhorn de 8 à 20 s Accord du fondateur : « Oui, après avoir soulagé pi2 ». pi2 est à 65 % depuis 10:17Z. ### Le réglage Réglage **`engine-replica-timeout`**, valeur Helm `defaultSettings.engineReplicaTimeout`. Doc Longhorn v1.9.1, [Settings Reference](https://longhorn.io/docs/1.9.1/references/settings/) : > « The time in seconds a v1 engine will wait for a response from a replica before marking it as failed. Values between 8 and 30 are allowed. » > « A V1 engine marks the last active replica as failed only after twice the configured number of seconds (timeout value x 2) have passed. » **Valeur retenue : 20 s.** - Le dernier réplica est déclaré mort à **40 s**. - Cela reste sous le **délai SCSI du noyau de 60 s**, relevé sur tous les disques Longhorn des 3 Pi. - À 30 s, on atteindrait 60 s : ce serait le noyau qui abandonnerait la commande. ### Le prix - Une vraie panne de réplica est constatée en **20 s au lieu de 8** (40 s au lieu de 16 pour le dernier), et les écritures du volume sont **suspendues** pendant ce temps. - ⚠ **Le réglage ne vaut que pour les moteurs démarrés après** : la valeur est passée en drapeau `--engine-replica-timeout` au lancement (relevé : `8` sur les moteurs en marche). Les 17 volumes attachés gardent 8 s jusqu'à leur prochain rattachement. - **Aucun rattachement n'a été forcé.** ### La voie Longhorn est installé par le HelmChart k3s que pose `factory/ansible/…/system/k3s_config.yml`. Le changement passe donc par **PR arcodange-org/factory#59**, fusionnée (`b63aefa`). - **Avant application** : - `helm template` v1.9.1 avant/après : une seule ligne diffère, dans la ConfigMap `longhorn-default-setting`, et aucun pod n'est recréé ; - la release en place est identique au rendu « avant » ; - `--check --diff` : un seul fichier modifié. - La tâche a reçu le tag `longhorn`. - ⚠ **Piège relevé** : sans tag, ce playbook **supprime le Deployment `traefik` dans le contexte kubectl COURANT**, qui peut être un autre cluster. - **Application** (10:30:54Z) : - `ansible-playbook … k3s_config.yml --tags longhorn` : **code 0**, seul `setup longhorn` est `changed` sur pi1 ; - release Helm `longhorn-install` passée de la révision **1 à la révision 2** (`Upgrade complete`, 10:31:31Z), job `helm-install-longhorn-install` terminé à 10:32:15Z. - **Vérifié** : - la ConfigMap porte `engine-replica-timeout: 20` ; - **`settings.longhorn.io/engine-replica-timeout` = 20** (valeur vivante, relue à 10:32:16Z) ; - aucun pod Longhorn recréé ni en erreur ; - 17 volumes `attached healthy`, 2 `detached` (les orphelins). 🤖 Generated with [Claude Code](https://claude.com/claude-code)
arcodange commented 2026-09-15 12:35:45 +02:00
Author
Owner
Copy Link
Copy Source

Relevé détaillé des restes Longhorn (12:38, lecture seule) : AUCUNE suppression

Consigne du fondateur : « Relevé détaillé, puis je te redemande ».

Sources : kubectl --context=default, puis sudo du -s en lecture sur /mnt/arcodange/longhorn/replicas/* des 3 Pi.

A. Objets d'attachement Kubernetes bloqués : 3 (pas 2)

Tous sont attacher=driver.longhorn.io, attached=true, sans ownerReferences, avec le finaliseur external-attacher/driver-longhorn-io. Leur détachement échoue en boucle sur persistentvolume "…" not found.

VolumeAttachment Nœud PV (inexistant) Créé Suppression demandée
csi-1ba4762a104044957423dc19216535d6ac11add9116ae95ac2044b4d17f1cdb1 pi2 pvc-04e9b068-c246-4159-92de-51b03ed1673f 2026-04-15 2026-04-21
csi-70710f117fba6b9b28067b4b93d6480301fac527aafa037a0dd8fbf28c8d44fe pi2 pvc-af0e2c87-0727-401f-bbb0-03226cacd795 2026-04-15 2026-05-09
csi-31d0889e9117b3703fcc4500acc855a18881ec9361f6fd0584cd1973ab4329f6 pi3 pvc-314fba0f-b5ca-44c5-96ce-8f4af42dbcc0 2026-04-15 2026-07-08

B. Volumes Longhorn orphelins (leur PV n'existe plus) : 3

Volume Taille / utilisé Créé Dernier propriétaire État Répliques (nœud, dossier, disque) Snapshots / sauvegardes
pvc-04e9b068-c246-4159-92de-51b03ed1673f 8 Gi / 7,27 Gi 2026-04-15 PVC tools/prometheus-server, pod prometheus-server-7dbcbc95f9-z4tr6 (dernière réf. 2026-04-15 09:45Z) detached (ce matin) pi1 …-01d014b7 7,3 G · pi2 …-e248ef10 7,3 G · pi3 …-9cead307 7,3 G (stopped) 1 snapshot / 0 backup
pvc-af0e2c87-0727-401f-bbb0-03226cacd795 1 Gi / 50 Mi 2026-04-15 PVC tools/redis-storage-redis-0, pod redis-0 (2026-04-15 09:45Z) detached (ce matin) pi1 …-668569fe 51 M · pi2 …-ff7acb09 51 M · pi3 …-a0d02191 51 M (stopped) 1 / 0
⚠ pvc-314fba0f-b5ca-44c5-96ce-8f4af42dbcc0 2 Gi / 97 Mi 2026-04-15 PVC tools/storage-prometheus-alertmanager-0, pod prometheus-alertmanager-0 (2026-04-15 09:45Z) encore attached sur pi3, healthy, avec un moteur et 3 répliques en marche pi1 …-bd816f11 · pi2 …-5c0196e0 · pi3 …-3cdbaa29 (running) 1 / 0

Preuve qu'aucun volume n'en dépend :

  • kubectl get pv <nom> rend NotFound pour les trois.
  • Aucun PVC n'a spec.volumeName égal à l'un d'eux. Les PVC des mêmes noms pointent ailleurs :
    • prometheus-server → pvc-015eabf4… ;
    • redis-storage-redis-0 → pvc-ae3e7fbc… (recréé le 2026-05-09) ;
    • storage-prometheus-alertmanager-0 → pvc-5db7810e… (recréé le 2026-07-08).
  • Aucun pod ne les monte.
  • spec.fromBackup, dataSource et backingImage sont vides : aucun volume n'a été cloné depuis eux.
  • Aucune sauvegarde (backupvolumes/backups) ne les concerne.
  • Le troisième reste attaché pour la même raison que les deux autres : un ticket csi-attacher resté posé. Il n'a pas été détaché (hors de l'accord, qui visait les deux de pi2).

C. Dossiers de répliques orphelins (orphans.longhorn.io) : 40, soit ≈ 68,9 Go de disque

Chacun est un dossier sur disque qu'aucune réplique ne référence : les 40 DataName ont été comparés aux dataDirectoryName de toutes les répliques, 0 correspondance. orphan-resource-auto-deletion est vide, donc Longhorn ne les supprimera pas seul.

Nœud Volume encore vivant ? Nombre Disque
pi1 oui (anciennes copies) 2 7 931 Mo
pi2 oui 5 11 114 Mo
pi2 non (volume disparu, sans PV) 4 492 Mo
pi3 oui 16 27 909 Mo
pi3 non 13 21 487 Mo
Liste complète (nœud, dossier, Mo, volume existe, créé) 
pi1 pvc-015eabf4-9baa-4b40-94f5-d20541e56209-84885c25 7915 oui 2026-08-25
pi1 pvc-01b93e30-886c-4056-aef6-8e7cdde200a0-39971252 16 oui 2026-08-25
pi2 pvc-1251909b-3cef-40c6-881c-3bb6e929a596-e7a20fdf 1544 oui 2026-09-04
pi2 pvc-14ccc47e-0b8c-49d4-97bb-70e550f644b0-09021065 121 NON 2026-09-04
pi2 pvc-6d2ea1c7-9327-4992-a02c-93ae604eda70-c7f287d8 229 oui 2026-08-11
pi2 pvc-7971918e-e47f-4739-a976-965ea2d770b4-2028617e 1087 oui 2026-09-04
pi2 pvc-ca5567d3-a682-4cee-8ff1-2b8e23260635-b537ca60 521 oui 2026-09-04
pi2 pvc-cc8a3cbb-dbc2-47a2-a0cc-a02136122b90-cd16e459 25 NON 2026-08-15
pi2 pvc-d1d5482b-81c8-4d7c-a528-7a57ef47a5ce-e0a8cdbc 88 NON 2026-08-15
pi2 pvc-efda1d2f-1db8-46dd-9a97-3d11f1807ffa-30c849a6 7733 oui 2026-09-04
pi2 pvc-fca13978-32ac-43f2-82c7-7fc7ca6233c8-4749b404 258 NON 2026-08-15
pi3 pvc-1251909b-3cef-40c6-881c-3bb6e929a596-1163420b 2607 oui 2026-08-30
pi3 pvc-1251909b-3cef-40c6-881c-3bb6e929a596-3a569b0a 1368 oui 2026-08-30
pi3 pvc-1251909b-3cef-40c6-881c-3bb6e929a596-ccd05947 1 oui 2026-08-30
pi3 pvc-14ccc47e-0b8c-49d4-97bb-70e550f644b0-3856d64d 121 NON 2026-08-30
pi3 pvc-2e60385f-e2f4-4c41-921f-9d1171338435-48e27d5a 192 NON 2026-08-30
pi3 pvc-6d2ea1c7-9327-4992-a02c-93ae604eda70-0e73550d 229 oui 2026-08-30
pi3 pvc-6d2ea1c7-9327-4992-a02c-93ae604eda70-787ffefa 229 oui 2026-08-30
pi3 pvc-6d2ea1c7-9327-4992-a02c-93ae604eda70-e0f58d64 229 oui 2026-08-30
pi3 pvc-7971918e-e47f-4739-a976-965ea2d770b4-33191046 1085 oui 2026-08-30
pi3 pvc-7971918e-e47f-4739-a976-965ea2d770b4-88fc1dfc 981 oui 2026-08-30
pi3 pvc-7971918e-e47f-4739-a976-965ea2d770b4-b5c5530d 1087 oui 2026-08-30
pi3 pvc-88e18c7f-2cfd-45e3-be5b-78c31ab829e9-5d508830 8805 NON 2026-08-30
pi3 pvc-88e18c7f-2cfd-45e3-be5b-78c31ab829e9-92c0ebfd 1263 NON 2026-08-30
pi3 pvc-88e18c7f-2cfd-45e3-be5b-78c31ab829e9-deea6182 10617 NON 2026-08-30
pi3 pvc-abe09e90-2c3f-4b6a-a09d-80d953bd57c5-a748d11b 17 NON 2026-08-30
pi3 pvc-aed7f2c4-1948-487a-8d10-d8a1372289b4-3452358f 100 NON 2026-08-30
pi3 pvc-aed7f2c4-1948-487a-8d10-d8a1372289b4-826f05aa 138 NON 2026-08-30
pi3 pvc-ca5567d3-a682-4cee-8ff1-2b8e23260635-0ed6f691 445 oui 2026-08-30
pi3 pvc-ca5567d3-a682-4cee-8ff1-2b8e23260635-808d72b4 521 oui 2026-08-30
pi3 pvc-ca5567d3-a682-4cee-8ff1-2b8e23260635-9051ef48 420 oui 2026-08-30
pi3 pvc-cc8a3cbb-dbc2-47a2-a0cc-a02136122b90-011b54b3 25 NON 2026-08-30
pi3 pvc-cc8a3cbb-dbc2-47a2-a0cc-a02136122b90-a24fd91e 25 NON 2026-08-30
pi3 pvc-cdd434d1-88b4-4588-8fd2-8c7eafc56d07-998f49ff 30 oui 2026-08-30
pi3 pvc-d1d5482b-81c8-4d7c-a528-7a57ef47a5ce-6a730f00 88 NON 2026-08-30
pi3 pvc-d1d5482b-81c8-4d7c-a528-7a57ef47a5ce-75da16fd 80 NON 2026-08-30
pi3 pvc-efda1d2f-1db8-46dd-9a97-3d11f1807ffa-62fb04c9 7733 oui 2026-08-30
pi3 pvc-efda1d2f-1db8-46dd-9a97-3d11f1807ffa-688f30f5 1623 oui 2026-08-30
pi3 pvc-efda1d2f-1db8-46dd-9a97-3d11f1807ffa-69454dd0 9321 oui 2026-08-30
pi3 pvc-f9fe3504-70ce-4401-8cda-bc6bb68bc1bf-418df608 16 NON 2026-08-30

Volumes disparus (ni volume Longhorn, ni PV, ni VolumeAttachment) auxquels appartiennent les 17 dossiers « NON » :
pvc-14ccc47e-0b8c-49d4-97bb-70e550f644b0, pvc-2e60385f-e2f4-4c41-921f-9d1171338435, pvc-88e18c7f-2cfd-45e3-be5b-78c31ab829e9 (≈ 20,7 Go à lui seul), pvc-abe09e90-2c3f-4b6a-a09d-80d953bd57c5, pvc-aed7f2c4-1948-487a-8d10-d8a1372289b4, pvc-cc8a3cbb-dbc2-47a2-a0cc-a02136122b90, pvc-d1d5482b-81c8-4d7c-a528-7a57ef47a5ce, pvc-f9fe3504-70ce-4401-8cda-bc6bb68bc1bf, pvc-fca13978-32ac-43f2-82c7-7fc7ca6233c8.

⚠ Pour les dossiers « oui », le volume vit toujours : ce sont d'anciennes copies laissées par des reconstructions. Les répliques actives sont ailleurs. Avant toute suppression, il faudrait vérifier volume par volume qu'il a bien 3 répliques running ailleurs.

D. Divers

  • Deux dossiers sans réplique ni orphelin enregistré : pvc-cdd434d1-…-3a461d4d.empty sur pi2 et pvc-cdd434d1-…-704d7933.empty sur pi3, 1 Mo chacun (url-shortener).
  • Nœuds de périphérique périmés sur pi2 : /dev/longhorn/pvc-6d2ea1c7… (audit Vault), pvc-ae3e7fbc… (redis) et pvc-ca5567d3… (données Vault), datés du 2026-08-03. Ces trois volumes sont attachés sur pi3. Leurs numéros majeur:mineur (8:96, 8:32, 8:80) peuvent désigner aujourd'hui d'autres disques. Rien n'a été touché.
  • Capacité des disques Longhorn (457 Gi chacun) : disponible pi1 128 Gi, pi2 245 Gi, pi3 104 Gi. pi3 porte à lui seul 49 Go d'orphelins.
  • Indice sur la cause du 04/09 (tools#53) : à 02:18:35–02:18:57Z ce jour-là, cinq dossiers de répliques de pi2 sont devenus orphelins d'un coup (ClickHouse, erp 7971918e, données Vault ca5567d3, backups-rwx efda1d2f, et 14ccc47e). Cela signifie que leurs répliques de pi2 ont été reconstruites ailleurs. L'erreur ext4 de ClickHouse suit 24 minutes plus tard (02:42Z). C'est compatible avec la même panne de pi2, mais ce n'est pas prouvé.

Rien n'a été supprimé ni détaché dans ce relevé. Décisions à prendre par le fondateur :

  1. détacher pvc-314fba0f ;
  2. retirer les finaliseurs des 3 VolumeAttachment ;
  3. supprimer les 3 volumes orphelins ;
  4. supprimer tout ou partie des 40 dossiers orphelins.

🤖 Generated with Claude Code

## Relevé détaillé des restes Longhorn (12:38, lecture seule) : AUCUNE suppression Consigne du fondateur : « Relevé détaillé, puis je te redemande ». Sources : `kubectl --context=default`, puis `sudo du -s` en lecture sur `/mnt/arcodange/longhorn/replicas/*` des 3 Pi. ### A. Objets d'attachement Kubernetes bloqués : **3** (pas 2) Tous sont `attacher=driver.longhorn.io`, `attached=true`, sans `ownerReferences`, avec le finaliseur `external-attacher/driver-longhorn-io`. Leur détachement échoue en boucle sur `persistentvolume "…" not found`. | VolumeAttachment | Nœud | PV (inexistant) | Créé | Suppression demandée | |---|---|---|---|---| | `csi-1ba4762a104044957423dc19216535d6ac11add9116ae95ac2044b4d17f1cdb1` | pi2 | `pvc-04e9b068-c246-4159-92de-51b03ed1673f` | 2026-04-15 | **2026-04-21** | | `csi-70710f117fba6b9b28067b4b93d6480301fac527aafa037a0dd8fbf28c8d44fe` | pi2 | `pvc-af0e2c87-0727-401f-bbb0-03226cacd795` | 2026-04-15 | **2026-05-09** | | `csi-31d0889e9117b3703fcc4500acc855a18881ec9361f6fd0584cd1973ab4329f6` | **pi3** | `pvc-314fba0f-b5ca-44c5-96ce-8f4af42dbcc0` | 2026-04-15 | **2026-07-08** | ### B. Volumes Longhorn orphelins (leur PV n'existe plus) : **3** | Volume | Taille / utilisé | Créé | Dernier propriétaire | État | Répliques (nœud, dossier, disque) | Snapshots / sauvegardes | |---|---|---|---|---|---|---| | `pvc-04e9b068-c246-4159-92de-51b03ed1673f` | 8 Gi / 7,27 Gi | 2026-04-15 | PVC `tools/prometheus-server`, pod `prometheus-server-7dbcbc95f9-z4tr6` (dernière réf. 2026-04-15 09:45Z) | **detached** (ce matin) | pi1 `…-01d014b7` 7,3 G · pi2 `…-e248ef10` 7,3 G · pi3 `…-9cead307` 7,3 G (`stopped`) | 1 snapshot / 0 backup | | `pvc-af0e2c87-0727-401f-bbb0-03226cacd795` | 1 Gi / 50 Mi | 2026-04-15 | PVC `tools/redis-storage-redis-0`, pod `redis-0` (2026-04-15 09:45Z) | **detached** (ce matin) | pi1 `…-668569fe` 51 M · pi2 `…-ff7acb09` 51 M · pi3 `…-a0d02191` 51 M (`stopped`) | 1 / 0 | | ⚠ `pvc-314fba0f-b5ca-44c5-96ce-8f4af42dbcc0` | 2 Gi / 97 Mi | 2026-04-15 | PVC `tools/storage-prometheus-alertmanager-0`, pod `prometheus-alertmanager-0` (2026-04-15 09:45Z) | **encore attached sur pi3**, `healthy`, avec un moteur et 3 répliques **en marche** | pi1 `…-bd816f11` · pi2 `…-5c0196e0` · pi3 `…-3cdbaa29` (`running`) | 1 / 0 | **Preuve qu'aucun volume n'en dépend** : - `kubectl get pv <nom>` rend `NotFound` pour les trois. - Aucun PVC n'a `spec.volumeName` égal à l'un d'eux. Les PVC des mêmes noms pointent ailleurs : - `prometheus-server` → `pvc-015eabf4…` ; - `redis-storage-redis-0` → `pvc-ae3e7fbc…` (recréé le 2026-05-09) ; - `storage-prometheus-alertmanager-0` → `pvc-5db7810e…` (recréé le 2026-07-08). - Aucun pod ne les monte. - `spec.fromBackup`, `dataSource` et `backingImage` sont vides : aucun volume n'a été cloné depuis eux. - Aucune sauvegarde (`backupvolumes`/`backups`) ne les concerne. - Le troisième reste attaché pour la même raison que les deux autres : un ticket `csi-attacher` resté posé. **Il n'a pas été détaché** (hors de l'accord, qui visait les deux de pi2). ### C. Dossiers de répliques orphelins (`orphans.longhorn.io`) : **40**, soit **≈ 68,9 Go** de disque Chacun est un dossier sur disque qu'**aucune réplique ne référence** : les 40 `DataName` ont été comparés aux `dataDirectoryName` de toutes les répliques, **0 correspondance**. `orphan-resource-auto-deletion` est vide, donc Longhorn ne les supprimera pas seul. | Nœud | Volume encore vivant ? | Nombre | Disque | |---|---|---|---| | pi1 | oui (anciennes copies) | 2 | 7 931 Mo | | pi2 | oui | 5 | 11 114 Mo | | pi2 | **non** (volume disparu, sans PV) | 4 | 492 Mo | | pi3 | oui | 16 | 27 909 Mo | | pi3 | **non** | 13 | 21 487 Mo | <details><summary>Liste complète (nœud, dossier, Mo, volume existe, créé)</summary> ``` pi1 pvc-015eabf4-9baa-4b40-94f5-d20541e56209-84885c25 7915 oui 2026-08-25 pi1 pvc-01b93e30-886c-4056-aef6-8e7cdde200a0-39971252 16 oui 2026-08-25 pi2 pvc-1251909b-3cef-40c6-881c-3bb6e929a596-e7a20fdf 1544 oui 2026-09-04 pi2 pvc-14ccc47e-0b8c-49d4-97bb-70e550f644b0-09021065 121 NON 2026-09-04 pi2 pvc-6d2ea1c7-9327-4992-a02c-93ae604eda70-c7f287d8 229 oui 2026-08-11 pi2 pvc-7971918e-e47f-4739-a976-965ea2d770b4-2028617e 1087 oui 2026-09-04 pi2 pvc-ca5567d3-a682-4cee-8ff1-2b8e23260635-b537ca60 521 oui 2026-09-04 pi2 pvc-cc8a3cbb-dbc2-47a2-a0cc-a02136122b90-cd16e459 25 NON 2026-08-15 pi2 pvc-d1d5482b-81c8-4d7c-a528-7a57ef47a5ce-e0a8cdbc 88 NON 2026-08-15 pi2 pvc-efda1d2f-1db8-46dd-9a97-3d11f1807ffa-30c849a6 7733 oui 2026-09-04 pi2 pvc-fca13978-32ac-43f2-82c7-7fc7ca6233c8-4749b404 258 NON 2026-08-15 pi3 pvc-1251909b-3cef-40c6-881c-3bb6e929a596-1163420b 2607 oui 2026-08-30 pi3 pvc-1251909b-3cef-40c6-881c-3bb6e929a596-3a569b0a 1368 oui 2026-08-30 pi3 pvc-1251909b-3cef-40c6-881c-3bb6e929a596-ccd05947 1 oui 2026-08-30 pi3 pvc-14ccc47e-0b8c-49d4-97bb-70e550f644b0-3856d64d 121 NON 2026-08-30 pi3 pvc-2e60385f-e2f4-4c41-921f-9d1171338435-48e27d5a 192 NON 2026-08-30 pi3 pvc-6d2ea1c7-9327-4992-a02c-93ae604eda70-0e73550d 229 oui 2026-08-30 pi3 pvc-6d2ea1c7-9327-4992-a02c-93ae604eda70-787ffefa 229 oui 2026-08-30 pi3 pvc-6d2ea1c7-9327-4992-a02c-93ae604eda70-e0f58d64 229 oui 2026-08-30 pi3 pvc-7971918e-e47f-4739-a976-965ea2d770b4-33191046 1085 oui 2026-08-30 pi3 pvc-7971918e-e47f-4739-a976-965ea2d770b4-88fc1dfc 981 oui 2026-08-30 pi3 pvc-7971918e-e47f-4739-a976-965ea2d770b4-b5c5530d 1087 oui 2026-08-30 pi3 pvc-88e18c7f-2cfd-45e3-be5b-78c31ab829e9-5d508830 8805 NON 2026-08-30 pi3 pvc-88e18c7f-2cfd-45e3-be5b-78c31ab829e9-92c0ebfd 1263 NON 2026-08-30 pi3 pvc-88e18c7f-2cfd-45e3-be5b-78c31ab829e9-deea6182 10617 NON 2026-08-30 pi3 pvc-abe09e90-2c3f-4b6a-a09d-80d953bd57c5-a748d11b 17 NON 2026-08-30 pi3 pvc-aed7f2c4-1948-487a-8d10-d8a1372289b4-3452358f 100 NON 2026-08-30 pi3 pvc-aed7f2c4-1948-487a-8d10-d8a1372289b4-826f05aa 138 NON 2026-08-30 pi3 pvc-ca5567d3-a682-4cee-8ff1-2b8e23260635-0ed6f691 445 oui 2026-08-30 pi3 pvc-ca5567d3-a682-4cee-8ff1-2b8e23260635-808d72b4 521 oui 2026-08-30 pi3 pvc-ca5567d3-a682-4cee-8ff1-2b8e23260635-9051ef48 420 oui 2026-08-30 pi3 pvc-cc8a3cbb-dbc2-47a2-a0cc-a02136122b90-011b54b3 25 NON 2026-08-30 pi3 pvc-cc8a3cbb-dbc2-47a2-a0cc-a02136122b90-a24fd91e 25 NON 2026-08-30 pi3 pvc-cdd434d1-88b4-4588-8fd2-8c7eafc56d07-998f49ff 30 oui 2026-08-30 pi3 pvc-d1d5482b-81c8-4d7c-a528-7a57ef47a5ce-6a730f00 88 NON 2026-08-30 pi3 pvc-d1d5482b-81c8-4d7c-a528-7a57ef47a5ce-75da16fd 80 NON 2026-08-30 pi3 pvc-efda1d2f-1db8-46dd-9a97-3d11f1807ffa-62fb04c9 7733 oui 2026-08-30 pi3 pvc-efda1d2f-1db8-46dd-9a97-3d11f1807ffa-688f30f5 1623 oui 2026-08-30 pi3 pvc-efda1d2f-1db8-46dd-9a97-3d11f1807ffa-69454dd0 9321 oui 2026-08-30 pi3 pvc-f9fe3504-70ce-4401-8cda-bc6bb68bc1bf-418df608 16 NON 2026-08-30 ``` </details> **Volumes disparus** (ni volume Longhorn, ni PV, ni VolumeAttachment) auxquels appartiennent les 17 dossiers « NON » : `pvc-14ccc47e-0b8c-49d4-97bb-70e550f644b0`, `pvc-2e60385f-e2f4-4c41-921f-9d1171338435`, `pvc-88e18c7f-2cfd-45e3-be5b-78c31ab829e9` (≈ 20,7 Go à lui seul), `pvc-abe09e90-2c3f-4b6a-a09d-80d953bd57c5`, `pvc-aed7f2c4-1948-487a-8d10-d8a1372289b4`, `pvc-cc8a3cbb-dbc2-47a2-a0cc-a02136122b90`, `pvc-d1d5482b-81c8-4d7c-a528-7a57ef47a5ce`, `pvc-f9fe3504-70ce-4401-8cda-bc6bb68bc1bf`, `pvc-fca13978-32ac-43f2-82c7-7fc7ca6233c8`. ⚠ Pour les dossiers « oui », le volume vit toujours : ce sont d'**anciennes copies** laissées par des reconstructions. Les répliques actives sont ailleurs. Avant toute suppression, il faudrait vérifier volume par volume qu'il a bien 3 répliques `running` ailleurs. ### D. Divers - **Deux dossiers sans réplique ni orphelin enregistré** : `pvc-cdd434d1-…-3a461d4d.empty` sur pi2 et `pvc-cdd434d1-…-704d7933.empty` sur pi3, 1 Mo chacun (url-shortener). - **Nœuds de périphérique périmés sur pi2** : `/dev/longhorn/pvc-6d2ea1c7…` (audit Vault), `pvc-ae3e7fbc…` (redis) et `pvc-ca5567d3…` (données Vault), datés du **2026-08-03**. Ces trois volumes sont attachés sur **pi3**. Leurs numéros majeur:mineur (8:96, 8:32, 8:80) peuvent désigner aujourd'hui d'autres disques. Rien n'a été touché. - **Capacité des disques Longhorn** (457 Gi chacun) : disponible **pi1 128 Gi, pi2 245 Gi, pi3 104 Gi**. pi3 porte à lui seul 49 Go d'orphelins. - **Indice sur la cause du 04/09 (tools#53)** : à **02:18:35–02:18:57Z** ce jour-là, **cinq dossiers de répliques de pi2** sont devenus orphelins d'un coup (ClickHouse, erp `7971918e`, données Vault `ca5567d3`, `backups-rwx` `efda1d2f`, et `14ccc47e`). Cela signifie que leurs répliques de pi2 ont été reconstruites ailleurs. L'erreur ext4 de ClickHouse suit **24 minutes plus tard** (02:42Z). C'est compatible avec la même panne de pi2, mais ce n'est pas prouvé. **Rien n'a été supprimé ni détaché dans ce relevé.** Décisions à prendre par le fondateur : 1. détacher `pvc-314fba0f` ; 2. retirer les finaliseurs des 3 VolumeAttachment ; 3. supprimer les 3 volumes orphelins ; 4. supprimer tout ou partie des 40 dossiers orphelins. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
arcodange commented 2026-09-15 12:55:46 +02:00
Author
Owner
Copy Link
Copy Source

Étape 1 (12:56) : pvc-314fba0f détaché, sans rien supprimer

Accord du fondateur : « Le détacher, sans le supprimer ».

Preuves avant le geste

  • Le pod vivant prometheus-alertmanager-0 (pi3) monte le PVC storage-prometheus-alertmanager-0, lié à pvc-5db7810e… et non à pvc-314fba0f.
  • findmnt sur pi3 : 0 montage de 314fba0f.
  • kubectl get pv pvc-314fba0f… : NotFound (relevé précédent).

Geste

  • Même geste que pour les deux volumes de pi2 : API Longhorn (longhorn-frontend) POST /v1/volumes/pvc-314fba0f-b5ca-44c5-96ce-8f4af42dbcc0?action=detach avec {"hostId":"","forceDetach":true}.
  • HTTP 200 à 10:55:13Z.

Vérifié

  • state=detached à 10:55:24Z. Tickets de l'attachement Longhorn : {}.

  • 3 répliques conservées, toutes stopped :

    Nœud Réplique Dossier Disque
    pi1 r-3cff260a …-bd816f11 98 M
    pi2 r-a610e1d3 …-5c0196e0 98 M
    pi3 r-3df6864e …-3cdbaa29 98 M

  • Sur les 3 nœuds : 0 processus Longhorn pour ce volume, 0 périphérique /dev/longhorn.

  • Aucun effet de bord : prometheus-alertmanager-0 est toujours ready=true (0 redémarrage), et son vrai volume pvc-5db7810e est attached pi3 healthy.

Les 3 volumes orphelins sont désormais détachés et conservés.

🤖 Generated with Claude Code

## Étape 1 (12:56) : `pvc-314fba0f` détaché, sans rien supprimer Accord du fondateur : « Le détacher, sans le supprimer ». **Preuves avant le geste** - Le pod vivant `prometheus-alertmanager-0` (pi3) monte le PVC `storage-prometheus-alertmanager-0`, lié à **`pvc-5db7810e…`** et non à `pvc-314fba0f`. - `findmnt` sur pi3 : **0** montage de `314fba0f`. - `kubectl get pv pvc-314fba0f…` : `NotFound` (relevé précédent). **Geste** - Même geste que pour les deux volumes de pi2 : API Longhorn (`longhorn-frontend`) `POST /v1/volumes/pvc-314fba0f-b5ca-44c5-96ce-8f4af42dbcc0?action=detach` avec `{"hostId":"","forceDetach":true}`. - **HTTP 200** à 10:55:13Z. **Vérifié** - `state=detached` à 10:55:24Z. Tickets de l'attachement Longhorn : `{}`. - **3 répliques conservées**, toutes `stopped` : | Nœud | Réplique | Dossier | Disque | |---|---|---|---| | pi1 | `r-3cff260a` | `…-bd816f11` | 98 M | | pi2 | `r-a610e1d3` | `…-5c0196e0` | 98 M | | pi3 | `r-3df6864e` | `…-3cdbaa29` | 98 M | - Sur les 3 nœuds : 0 processus Longhorn pour ce volume, 0 périphérique `/dev/longhorn`. - Aucun effet de bord : `prometheus-alertmanager-0` est toujours `ready=true` (0 redémarrage), et son vrai volume `pvc-5db7810e` est `attached pi3 healthy`. Les **3 volumes orphelins** sont désormais détachés et **conservés**. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
arcodange commented 2026-09-15 12:56:58 +02:00
Author
Owner
Copy Link
Copy Source

Étape 2a (12:57) : finaliseurs retirés des 3 objets d'attachement bloqués

Accord du fondateur : « par étapes, avec preuve à chaque ligne ».

Preuves relevées juste avant chaque geste, et geste

VolumeAttachment PV référencé kubectl get pv PVC lié à ce PV Pods (via PVC / CSI en ligne) Volume Longhorn Geste Code
csi-1ba4762a104044957423dc19216535d6ac11add9116ae95ac2044b4d17f1cdb1 pvc-04e9b068-c246-4159-92de-51b03ed1673f rc=1, inexistant aucun aucun / 0 detached patch à 10:56:16Z 0
csi-70710f117fba6b9b28067b4b93d6480301fac527aafa037a0dd8fbf28c8d44fe pvc-af0e2c87-0727-401f-bbb0-03226cacd795 rc=1, inexistant aucun aucun / 0 detached patch à 10:56:22Z 0
csi-31d0889e9117b3703fcc4500acc855a18881ec9361f6fd0584cd1973ab4329f6 pvc-314fba0f-b5ca-44c5-96ce-8f4af42dbcc0 rc=1, inexistant aucun aucun / 0 detached patch à 10:56:27Z 0
  • Commande : kubectl --context=default patch volumeattachments.storage.k8s.io <nom> --type=json -p '[{"op":"remove","path":"/metadata/finalizers"}]'.
  • Garde-fou : le patch n'était lancé que si les trois preuves étaient vraies (PV absent, aucun PVC lié, aucun pod). Il n'y a pas eu d'écart.
  • Les pods ont été recherchés sur tous les namespaces, par leurs PVC (spec.volumes[].persistentVolumeClaim → spec.volumeName) et par leurs volumes CSI en ligne.

Vérifié

  • Les 3 objets rendent NotFound, 3 s après le patch. Ils étaient en suppression depuis avril, mai et juillet : ils ont disparu dès le finaliseur retiré.
  • Les 3 volumes Longhorn orphelins restent detached (relus à 10:56:40Z), 3 répliques chacun : aucun rattachement.
  • Il reste 16 VolumeAttachment dans le cluster, 0 en suppression, et tous visent un PV existant.
  • 16 volumes attached healthy, 3 detached.

Aucune donnée touchée. Suite : l'étape 2b, les 17 dossiers des volumes disparus.

🤖 Generated with Claude Code

## Étape 2a (12:57) : finaliseurs retirés des 3 objets d'attachement bloqués Accord du fondateur : « par étapes, avec preuve à chaque ligne ». **Preuves relevées juste avant chaque geste, et geste** | VolumeAttachment | PV référencé | `kubectl get pv` | PVC lié à ce PV | Pods (via PVC / CSI en ligne) | Volume Longhorn | Geste | Code | |---|---|---|---|---|---|---|---| | `csi-1ba4762a104044957423dc19216535d6ac11add9116ae95ac2044b4d17f1cdb1` | `pvc-04e9b068-c246-4159-92de-51b03ed1673f` | rc=1, inexistant | aucun | aucun / 0 | `detached` | patch à 10:56:16Z | **0** | | `csi-70710f117fba6b9b28067b4b93d6480301fac527aafa037a0dd8fbf28c8d44fe` | `pvc-af0e2c87-0727-401f-bbb0-03226cacd795` | rc=1, inexistant | aucun | aucun / 0 | `detached` | patch à 10:56:22Z | **0** | | `csi-31d0889e9117b3703fcc4500acc855a18881ec9361f6fd0584cd1973ab4329f6` | `pvc-314fba0f-b5ca-44c5-96ce-8f4af42dbcc0` | rc=1, inexistant | aucun | aucun / 0 | `detached` | patch à 10:56:27Z | **0** | - **Commande** : `kubectl --context=default patch volumeattachments.storage.k8s.io <nom> --type=json -p '[{"op":"remove","path":"/metadata/finalizers"}]'`. - **Garde-fou** : le patch n'était lancé que si les trois preuves étaient vraies (PV absent, aucun PVC lié, aucun pod). Il n'y a pas eu d'écart. - Les pods ont été recherchés sur tous les namespaces, par leurs PVC (`spec.volumes[].persistentVolumeClaim` → `spec.volumeName`) et par leurs volumes CSI en ligne. **Vérifié** - Les 3 objets rendent `NotFound`, 3 s après le patch. Ils étaient en suppression depuis avril, mai et juillet : ils ont disparu dès le finaliseur retiré. - Les 3 volumes Longhorn orphelins restent **`detached`** (relus à 10:56:40Z), **3 répliques chacun** : aucun rattachement. - Il reste 16 VolumeAttachment dans le cluster, **0 en suppression**, et tous visent un PV existant. - 16 volumes `attached healthy`, 3 `detached`. Aucune donnée touchée. Suite : l'étape 2b, les 17 dossiers des volumes disparus. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
arcodange commented 2026-09-15 13:04:19 +02:00
Author
Owner
Copy Link
Copy Source

Étape 2b (13:04) : 17 dossiers des 9 volumes disparus supprimés, avec preuve à chaque ligne. 21,5 Go libérés sur pi3

Accord du fondateur : « par étapes, avec preuve à chaque ligne ». Seul le périmètre autorisé a été touché.

Méthode

Voie choisie : la CR orphans.longhorn.io, pas rm par SSH. La doc Longhorn v1.9.1 (Orphaned Data Cleanup) dit que supprimer la ressource orphan efface le dossier de réplique correspondant. C'est le geste « Operation > Delete » de l'interface.

Deux raisons :

  • l'état de Longhorn reste cohérent (aucune CR ne pointe vers un dossier effacé) ;
  • aucune écriture par SSH n'a été nécessaire : SSH n'a servi qu'aux preuves en lecture.

Pour chaque dossier, un script (nettoyer-orphelin.sh) relève juste avant le geste :

Preuve Contrôle
P1 kubectl get volumes.longhorn.io <volume> → NotFound explicite. Une autre erreur d'API compte comme ambiguë.
P2 Liste fraîche de toutes les répliques (57) : 0 avec dataDirectoryName == dossier ou volumeName == volume.
P3a kubectl get pv <volume> → NotFound.
P3b Liste fraîche des PVC (16) : 0 avec spec.volumeName == volume.
P4 La CR orphan existe et désigne ce nœud et ce dossier.
P5 Sur le nœud : le dossier existe, sudo lsof +D <dossier> rend 0 ligne, fuser 0 pid, et 0 processus ne porte le nom du dossier.
  • Geste : DELETE /v1/orphans/<nom> sur l'API Longhorn, seulement si les 6 preuves sont vraies.
  • Vérification : la CR a disparu et sudo test -e <dossier> est faux.
  • Codes de sortie du script : 0 = supprimé et vérifié ; 10 = preuve ambiguë, rien fait ; 20 = vérification en échec, et la boucle s'arrête.

Sabotage de l'instrument, avant usage : le script, lancé à blanc sur le dossier vivant de la réplique MinIO sur pi3 (pvc-ebb2605f…-8341e129), a rougi sur les 6 preuves, code 10, sans aucun geste :

Preuve Résultat sur le dossier vivant
P1 volume trouvé
P2 3 répliques
P3 PV Bound, 1 PVC lié
P4 pas de CR
P5 lsof 4 lignes, fuser 3 pids, 1 processus

Lancé à blanc sur le premier dossier autorisé, il a rendu 0.

Les 17 lignes (toutes : 6 preuves vraies, code 0, HTTP 200, vérifié)

# Nœud Dossier Volume disparu Taille Geste (UTC)
1 pi3 pvc-f9fe3504-70ce-4401-8cda-bc6bb68bc1bf-418df608 pvc-f9fe3504… 16 Mo 10:58:49
2 pi2 pvc-14ccc47e-0b8c-49d4-97bb-70e550f644b0-09021065 pvc-14ccc47e… 121 Mo 10:59:12
3 pi2 pvc-cc8a3cbb-dbc2-47a2-a0cc-a02136122b90-cd16e459 pvc-cc8a3cbb… 25 Mo 10:59:21
4 pi2 pvc-d1d5482b-81c8-4d7c-a528-7a57ef47a5ce-e0a8cdbc pvc-d1d5482b… 88 Mo 10:59:52
5 pi2 pvc-fca13978-32ac-43f2-82c7-7fc7ca6233c8-4749b404 pvc-fca13978… 258 Mo 11:00:22
6 pi3 pvc-14ccc47e-0b8c-49d4-97bb-70e550f644b0-3856d64d pvc-14ccc47e… 121 Mo 11:00:52
7 pi3 pvc-2e60385f-e2f4-4c41-921f-9d1171338435-48e27d5a pvc-2e60385f… 192 Mo 11:00:53
8 pi3 pvc-88e18c7f-2cfd-45e3-be5b-78c31ab829e9-5d508830 pvc-88e18c7f… 8 805 Mo 11:01:00
9 pi3 pvc-88e18c7f-2cfd-45e3-be5b-78c31ab829e9-92c0ebfd pvc-88e18c7f… 1 263 Mo 11:01:29
10 pi3 pvc-88e18c7f-2cfd-45e3-be5b-78c31ab829e9-deea6182 pvc-88e18c7f… 10 617 Mo 11:02:03
11 pi3 pvc-abe09e90-2c3f-4b6a-a09d-80d953bd57c5-a748d11b pvc-abe09e90… 17 Mo 11:02:31
12 pi3 pvc-aed7f2c4-1948-487a-8d10-d8a1372289b4-3452358f pvc-aed7f2c4… 100 Mo 11:02:33
13 pi3 pvc-aed7f2c4-1948-487a-8d10-d8a1372289b4-826f05aa pvc-aed7f2c4… 138 Mo 11:02:35
14 pi3 pvc-cc8a3cbb-dbc2-47a2-a0cc-a02136122b90-011b54b3 pvc-cc8a3cbb… 25 Mo 11:02:36
15 pi3 pvc-cc8a3cbb-dbc2-47a2-a0cc-a02136122b90-a24fd91e pvc-cc8a3cbb… 25 Mo 11:02:38
16 pi3 pvc-d1d5482b-81c8-4d7c-a528-7a57ef47a5ce-6a730f00 pvc-d1d5482b… 88 Mo 11:02:39
17 pi3 pvc-d1d5482b-81c8-4d7c-a528-7a57ef47a5ce-75da16fd pvc-d1d5482b… 80 Mo 11:02:41

Aucune preuve ambiguë : aucun dossier écarté.

Espace libéré

Nœud Dossiers Somme des du df /mnt/arcodange utilisé (avant → après) Disponible Longhorn
pi1 0 0 337 307 → 337 319 M (bruit) 131 000 Mi (inchangé)
pi2 4 492 Mo 217 374 → 216 898 M (−476 M) 250 900 → 251 400 Mi
pi3 13 21 487 Mo 361 870 → 340 404 M (−21 466 M) 106 400 → 127 400 Mi

Total : environ 21,9 Go libérés, presque tout sur pi3, qui était le disque Longhorn le plus plein.

Vérifications d'ensemble (11:03Z)

  • 0 dossier des 9 volumes disparus sur pi2 et pi3 (ls -d …/replicas/pvc-<id>*).
  • 23 CR orphan restantes, toutes d'anciennes copies de volumes vivants. Aucune ne vient d'un volume disparu, aucune n'est en suppression.
    • ⚠ Un listage pris à 11:02:4x en montrait 25 : deux CR supprimées (lignes 11 et 12) y figuraient encore. Relues à 11:03:08, elles avaient disparu, et leur dossier est absent. Transitoire de la suppression, état final vérifié.
  • Les 23 copies conservées sont toutes présentes sur disque : pi1 2/2, pi2 5/5, pi3 16/16.
  • 57 répliques (inchangé). 16 volumes attached healthy, 3 detached (les orphelins conservés).

Non touché (INTERDIT sans nouvel accord ligne par ligne)

  • les 23 anciennes copies de volumes vivants (≈ 46,9 Go) ;
  • les 3 volumes orphelins détachés : pvc-04e9b068, pvc-af0e2c87, pvc-314fba0f (≈ 22,3 Go de répliques) ;
  • les deux dossiers pvc-cdd434d1-…-.empty (1 Mo chacun, hors liste).

Délai de 20 s : « au fil de l'eau, sans forcer »

Aucun volume n'a été rattaché. Les moteurs en marche gardent --engine-replica-timeout 8. Chacun passera à 20 s à son prochain démarrage naturel : redéploiement, déplacement de pod ou redémarrage de nœud.

🤖 Generated with Claude Code

## Étape 2b (13:04) : 17 dossiers des 9 volumes disparus supprimés, avec preuve à chaque ligne. 21,5 Go libérés sur pi3 Accord du fondateur : « par étapes, avec preuve à chaque ligne ». Seul le périmètre autorisé a été touché. ### Méthode **Voie choisie : la CR `orphans.longhorn.io`, pas `rm` par SSH.** La doc Longhorn v1.9.1 ([Orphaned Data Cleanup](https://longhorn.io/docs/1.9.1/advanced-resources/data-cleanup/orphaned-data-cleanup/)) dit que supprimer la ressource orphan efface le dossier de réplique correspondant. C'est le geste « Operation > Delete » de l'interface. Deux raisons : - l'état de Longhorn reste cohérent (aucune CR ne pointe vers un dossier effacé) ; - **aucune écriture par SSH n'a été nécessaire** : SSH n'a servi qu'aux preuves en lecture. Pour chaque dossier, un script (`nettoyer-orphelin.sh`) relève **juste avant le geste** : | Preuve | Contrôle | |---|---| | P1 | `kubectl get volumes.longhorn.io <volume>` → `NotFound` explicite. Une autre erreur d'API compte comme ambiguë. | | P2 | Liste fraîche de **toutes** les répliques (57) : 0 avec `dataDirectoryName == dossier` ou `volumeName == volume`. | | P3a | `kubectl get pv <volume>` → `NotFound`. | | P3b | Liste fraîche des PVC (16) : 0 avec `spec.volumeName == volume`. | | P4 | La CR orphan existe et désigne **ce** nœud et **ce** dossier. | | P5 | Sur le nœud : le dossier existe, `sudo lsof +D <dossier>` rend 0 ligne, `fuser` 0 pid, et 0 processus ne porte le nom du dossier. | - **Geste** : `DELETE /v1/orphans/<nom>` sur l'API Longhorn, seulement si les 6 preuves sont vraies. - **Vérification** : la CR a disparu **et** `sudo test -e <dossier>` est faux. - Codes de sortie du script : 0 = supprimé et vérifié ; 10 = preuve ambiguë, rien fait ; 20 = vérification en échec, et la boucle s'arrête. **Sabotage de l'instrument, avant usage** : le script, lancé à blanc sur le dossier **vivant** de la réplique MinIO sur pi3 (`pvc-ebb2605f…-8341e129`), a rougi sur **les 6 preuves**, code **10**, sans aucun geste : | Preuve | Résultat sur le dossier vivant | |---|---| | P1 | volume trouvé | | P2 | 3 répliques | | P3 | PV `Bound`, 1 PVC lié | | P4 | pas de CR | | P5 | `lsof` 4 lignes, `fuser` 3 pids, 1 processus | Lancé à blanc sur le premier dossier autorisé, il a rendu **0**. ### Les 17 lignes (toutes : 6 preuves vraies, code 0, HTTP 200, vérifié) | # | Nœud | Dossier | Volume disparu | Taille | Geste (UTC) | |---|---|---|---|---|---| | 1 | pi3 | `pvc-f9fe3504-70ce-4401-8cda-bc6bb68bc1bf-418df608` | `pvc-f9fe3504…` | 16 Mo | 10:58:49 | | 2 | pi2 | `pvc-14ccc47e-0b8c-49d4-97bb-70e550f644b0-09021065` | `pvc-14ccc47e…` | 121 Mo | 10:59:12 | | 3 | pi2 | `pvc-cc8a3cbb-dbc2-47a2-a0cc-a02136122b90-cd16e459` | `pvc-cc8a3cbb…` | 25 Mo | 10:59:21 | | 4 | pi2 | `pvc-d1d5482b-81c8-4d7c-a528-7a57ef47a5ce-e0a8cdbc` | `pvc-d1d5482b…` | 88 Mo | 10:59:52 | | 5 | pi2 | `pvc-fca13978-32ac-43f2-82c7-7fc7ca6233c8-4749b404` | `pvc-fca13978…` | 258 Mo | 11:00:22 | | 6 | pi3 | `pvc-14ccc47e-0b8c-49d4-97bb-70e550f644b0-3856d64d` | `pvc-14ccc47e…` | 121 Mo | 11:00:52 | | 7 | pi3 | `pvc-2e60385f-e2f4-4c41-921f-9d1171338435-48e27d5a` | `pvc-2e60385f…` | 192 Mo | 11:00:53 | | 8 | pi3 | `pvc-88e18c7f-2cfd-45e3-be5b-78c31ab829e9-5d508830` | `pvc-88e18c7f…` | 8 805 Mo | 11:01:00 | | 9 | pi3 | `pvc-88e18c7f-2cfd-45e3-be5b-78c31ab829e9-92c0ebfd` | `pvc-88e18c7f…` | 1 263 Mo | 11:01:29 | | 10 | pi3 | `pvc-88e18c7f-2cfd-45e3-be5b-78c31ab829e9-deea6182` | `pvc-88e18c7f…` | 10 617 Mo | 11:02:03 | | 11 | pi3 | `pvc-abe09e90-2c3f-4b6a-a09d-80d953bd57c5-a748d11b` | `pvc-abe09e90…` | 17 Mo | 11:02:31 | | 12 | pi3 | `pvc-aed7f2c4-1948-487a-8d10-d8a1372289b4-3452358f` | `pvc-aed7f2c4…` | 100 Mo | 11:02:33 | | 13 | pi3 | `pvc-aed7f2c4-1948-487a-8d10-d8a1372289b4-826f05aa` | `pvc-aed7f2c4…` | 138 Mo | 11:02:35 | | 14 | pi3 | `pvc-cc8a3cbb-dbc2-47a2-a0cc-a02136122b90-011b54b3` | `pvc-cc8a3cbb…` | 25 Mo | 11:02:36 | | 15 | pi3 | `pvc-cc8a3cbb-dbc2-47a2-a0cc-a02136122b90-a24fd91e` | `pvc-cc8a3cbb…` | 25 Mo | 11:02:38 | | 16 | pi3 | `pvc-d1d5482b-81c8-4d7c-a528-7a57ef47a5ce-6a730f00` | `pvc-d1d5482b…` | 88 Mo | 11:02:39 | | 17 | pi3 | `pvc-d1d5482b-81c8-4d7c-a528-7a57ef47a5ce-75da16fd` | `pvc-d1d5482b…` | 80 Mo | 11:02:41 | **Aucune preuve ambiguë : aucun dossier écarté.** ### Espace libéré | Nœud | Dossiers | Somme des `du` | `df /mnt/arcodange` utilisé (avant → après) | Disponible Longhorn | |---|---|---|---|---| | pi1 | 0 | 0 | 337 307 → 337 319 M (bruit) | 131 000 Mi (inchangé) | | pi2 | 4 | 492 Mo | 217 374 → 216 898 M (**−476 M**) | 250 900 → 251 400 Mi | | pi3 | 13 | 21 487 Mo | 361 870 → 340 404 M (**−21 466 M**) | **106 400 → 127 400 Mi** | **Total : environ 21,9 Go libérés**, presque tout sur pi3, qui était le disque Longhorn le plus plein. ### Vérifications d'ensemble (11:03Z) - **0 dossier** des 9 volumes disparus sur pi2 et pi3 (`ls -d …/replicas/pvc-<id>*`). - **23 CR orphan** restantes, **toutes** d'anciennes copies de volumes vivants. Aucune ne vient d'un volume disparu, aucune n'est en suppression. - ⚠ Un listage pris à 11:02:4x en montrait 25 : deux CR supprimées (lignes 11 et 12) y figuraient encore. Relues à 11:03:08, elles avaient disparu, et leur dossier est absent. Transitoire de la suppression, état final vérifié. - **Les 23 copies conservées sont toutes présentes sur disque** : pi1 2/2, pi2 5/5, pi3 16/16. - 57 répliques (inchangé). 16 volumes `attached healthy`, 3 `detached` (les orphelins conservés). ### Non touché (INTERDIT sans nouvel accord ligne par ligne) - les **23 anciennes copies de volumes vivants** (≈ 46,9 Go) ; - les **3 volumes orphelins détachés** : `pvc-04e9b068`, `pvc-af0e2c87`, `pvc-314fba0f` (≈ 22,3 Go de répliques) ; - les deux dossiers `pvc-cdd434d1-…-.empty` (1 Mo chacun, hors liste). ### Délai de 20 s : « au fil de l'eau, sans forcer » Aucun volume n'a été rattaché. Les moteurs en marche gardent `--engine-replica-timeout 8`. Chacun passera à 20 s à son prochain démarrage naturel : redéploiement, déplacement de pod ou redémarrage de nœud. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
arcodange commented 2026-09-15 13:11:28 +02:00
Author
Owner
Copy Link
Copy Source

Nettoyage final, étape 1 (13:12) : les 3 volumes orphelins détachés sont supprimés

Décision du fondateur : « ne conserver que ce qui sert aux applications ».

Méthode

Script par volume. Les preuves sont relevées juste avant chaque geste, et le script refuse (code 10) dès qu'une seule manque.

Preuve Contrôle
P0 Le volume est detached.
P1 Aucun PV ne le référence, ni par nom ni par spec.csi.volumeHandle. Liste fraîche de 16 PV.
P2 Aucune PVC n'a spec.volumeName égal au volume. Liste fraîche de 16 PVC.
P3 Aucun pod n'utilise un claim qui y mène, ni un volume CSI en ligne (113 pods relus).
P4 Le service d'origine tourne sur un autre volume attached/healthy, avec ses pods Running et prêts.
  • Geste : DELETE /v1/volumes/<nom> sur l'API Longhorn.
  • Vérification : le volume et ses répliques ont disparu des CR, et plus aucun dossier du volume ne reste sur pi1, pi2 et pi3.
  • Sabotage de l'instrument, avant usage : lancé à blanc sur le volume vivant de Prometheus, le script a refusé sur les 5 preuves, code 10, sans aucun geste.

Résultat (3 sur 3 : preuves vraies, HTTP 200, vérifié, code 0)

Volume supprimé (ancien usage) Service d'origine, vérifié sain sur Répliques supprimées Libéré
ancien redis-storage-redis-0 redis-0 prêt, volume actuel attached/healthy pi1, pi2, pi3 : 51 Mo chacune 153 Mo
ancien storage-prometheus-alertmanager-0 prometheus-alertmanager-0 prêt, volume actuel attached/healthy pi1, pi2, pi3 : 98 Mo chacune 294 Mo
ancien prometheus-server prometheus-server prêt, volume actuel attached/healthy pi1, pi2, pi3 : 7 445 Mo chacune 22 335 Mo

Chaque suppression a pris 5 s, et Longhorn a effacé lui-même les dossiers : aucun retrait à la main n'a été nécessaire.

Suite : l'étape 2, les 23 anciennes copies de volumes vivants.

🤖 Generated with Claude Code

## Nettoyage final, étape 1 (13:12) : les 3 volumes orphelins détachés sont supprimés Décision du fondateur : « ne conserver que ce qui sert aux applications ». ### Méthode Script par volume. Les preuves sont relevées juste avant chaque geste, et le script **refuse** (code 10) dès qu'une seule manque. | Preuve | Contrôle | |---|---| | P0 | Le volume est `detached`. | | P1 | Aucun PV ne le référence, ni par nom ni par `spec.csi.volumeHandle`. Liste fraîche de 16 PV. | | P2 | Aucune PVC n'a `spec.volumeName` égal au volume. Liste fraîche de 16 PVC. | | P3 | Aucun pod n'utilise un claim qui y mène, ni un volume CSI en ligne (113 pods relus). | | P4 | Le service d'origine tourne sur un **autre** volume `attached/healthy`, avec ses pods `Running` et prêts. | - **Geste** : `DELETE /v1/volumes/<nom>` sur l'API Longhorn. - **Vérification** : le volume et ses répliques ont disparu des CR, et plus aucun dossier du volume ne reste sur pi1, pi2 et pi3. - **Sabotage de l'instrument, avant usage** : lancé à blanc sur le volume **vivant** de Prometheus, le script a refusé sur les 5 preuves, code **10**, sans aucun geste. ### Résultat (3 sur 3 : preuves vraies, HTTP 200, vérifié, code 0) | Volume supprimé (ancien usage) | Service d'origine, vérifié sain sur | Répliques supprimées | Libéré | |---|---|---|---| | ancien `redis-storage-redis-0` | `redis-0` prêt, volume actuel `attached/healthy` | pi1, pi2, pi3 : 51 Mo chacune | 153 Mo | | ancien `storage-prometheus-alertmanager-0` | `prometheus-alertmanager-0` prêt, volume actuel `attached/healthy` | pi1, pi2, pi3 : 98 Mo chacune | 294 Mo | | ancien `prometheus-server` | `prometheus-server` prêt, volume actuel `attached/healthy` | pi1, pi2, pi3 : 7 445 Mo chacune | 22 335 Mo | Chaque suppression a pris 5 s, et Longhorn a effacé lui-même les dossiers : **aucun retrait à la main n'a été nécessaire**. Suite : l'étape 2, les 23 anciennes copies de volumes vivants. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
arcodange commented 2026-09-15 13:19:31 +02:00
Author
Owner
Copy Link
Copy Source

Nettoyage final : bilan (13:18)

Décision du fondateur : « ne conserver que ce qui sert aux applications ».

Ce commentaire ne cite aucun identifiant : les volumes y sont désignés par leur application.

Méthode, étapes 2 et 3

Script par copie, avec les preuves relevées juste avant chaque geste :

Preuve Contrôle
V Le volume vivant est attached/healthy, avec toutes ses répliques running (3/3, autant que voulu). Toutes sont en mode RW dans le moteur, et aucune reconstruction n'est en cours.
R Aucun objet replicas.longhorn.io n'a spec.dataDirectoryName égal au nom exact du dossier. Pour les .empty, on compare aussi au nom sans ce suffixe.
C La ressource orphan désigne bien ce nœud et ce dossier.
F Sur le nœud : lsof, fuser et ps ne montrent rien, et la taille est relevée.

Déroulé par volume :

  1. Toutes les copies du volume passent d'abord à blanc. Si une seule preuve manque, aucune copie du volume n'est touchée.
  2. Les copies sont ensuite supprimées une à une, par la ressource orphan de l'API Longhorn.
  3. Après chaque suppression, on vérifie que la ressource et le dossier ont disparu et que le volume est toujours sain.

Sabotage de l'instrument, avant usage : lancé sur le dossier actif de la réplique de ClickHouse sur pi1, le script a refusé sur R, C et F (lsof 5 lignes, fuser 4 pids, 1 processus), code 10, sans aucun geste.

1. Ce qui a été supprimé

Étape 1 : les 3 volumes orphelins (anciens redis, alertmanager, prometheus-server), supprimés par l'API Longhorn. Longhorn a effacé lui-même leurs dossiers.

pi1 pi2 pi3
ancien redis 51 Mo 51 Mo 51 Mo
ancien alertmanager 98 Mo 98 Mo 98 Mo
ancien prometheus-server 7 445 Mo 7 445 Mo 7 445 Mo
Sous-total 7 594 Mo 7 594 Mo 7 594 Mo

Étape 2 : les 23 anciennes copies de volumes vivants. 23 sur 23 : preuves vraies, HTTP 200, vérifiées, volume toujours sain après chaque suppression.

Application pi1 pi2 pi3
prometheus-server 7 915 Mo (1) — —
crowdsec (config) 16 Mo (1) — —
ClickHouse — 1 544 Mo (1) 3 976 Mo (3)
Vault (audit) — 229 Mo (1) 687 Mo (3)
ERP — 1 087 Mo (1) 3 153 Mo (3)
Vault (données) — 521 Mo (1) 1 386 Mo (3)
url-shortener — — 30 Mo (1)
sauvegardes Longhorn (backups-rwx) — 7 733 Mo (1) 18 677 Mo (3)
Sous-total 7 931 Mo 11 114 Mo 27 909 Mo

Total supprimé par ce nettoyage :

pi1 pi2 pi3 Total
15 525 Mo 18 708 Mo 35 503 Mo 69 736 Mo

S'y ajoutent les 17 dossiers des volumes disparus supprimés plus tôt : pi2 492 Mo, pi3 21 487 Mo.

2. Ce qui a été gardé, et pourquoi

  • Les 48 répliques actives des 16 volumes des applications : toutes running.
  • Les deux dossiers .empty d'url-shortener (pi2 et pi3, environ 1 Mo sur disque chacun), non supprimés.
    • Sur pi2, le nom de ce dossier, sans le suffixe .empty, est exactement le dossier de données de la réplique active du volume.
    • Aucune réplique ne pointe vers le nom exact du .empty. Mais cette parenté de nom est un fait qui contredit « aucune réplique ne le référence ». La règle « une preuve manque, on ne touche à aucune copie du volume » s'applique donc aux deux dossiers.
    • Ils datent du 2026-04-14, le lendemain de la coupure de courant du 13/04 et de sa récupération (dépôt factory, outillage recover).
    • Leur sort attend un nouvel accord.

3. Espace libre sur les disques Longhorn

Nœud df disponible avant (11:09Z) après (11:17Z) Gain Disponible Longhorn avant → après
pi1 107 159 Mo 122 663 Mo +15 504 Mo 131 000 → 146 500 Mi
pi2 227 582 Mo 246 265 Mo +18 683 Mo 251 400 → 270 100 Mi
pi3 104 075 Mo 139 550 Mo +35 475 Mo 127 900 → 163 400 Mi

Sur la journée, avant l'étape 2b (10:57Z), pi3 n'avait que 82 623 Mo disponibles. Il en a désormais 139 550.

4. État des volumes (11:17Z)

  • 16 volumes, tous attached/healthy, tous portés par une application : erp, erp-sandbox, traefik, backups-rwx, prospection, Vault ×2, ClickHouse, crowdsec ×2, MinIO, prometheus-server, redis, loki, alertmanager, url-shortener.
  • 48 répliques, toutes running. 0 ressource orphan.
  • Cohérence disque ↔ Longhorn : pi1 a 16 dossiers pour 16 répliques. pi2 et pi3 ont 17 dossiers pour 16 répliques, la différence étant le .empty gardé sur chacun.
  • Le délai de 20 s continue de s'appliquer au fil de l'eau, sans rattachement forcé.

⚠ Hors périmètre, constaté pendant le bilan : Plausible est retombé

  • Le pod plausible de la dernière révision (déclenchée à 10:46Z par la rotation de ses identifiants de base de données) tourne sur pi2.
  • Il a été disponible de 10:49 à 11:08Z. Depuis, il boucle : tué par sa sonde de vivacité (délai d'une seconde, pas de sonde de démarrage), code 137, environ 56 s après chaque départ, sans une ligne de journal.
  • ArgoCD affiche plausible en Progressing.
  • ClickHouse n'est pas en cause : 0 erreur d'E/S sur les 20 dernières minutes, et Plausible n'a pas de volume Longhorn.
  • La connexion à la base aboutit : pgbouncer voit les connexions s'ouvrir, puis se fermer à la mort du conteneur.
  • Cause non établie. Je n'ai rien fait : suivi dans tools#53.

🤖 Generated with Claude Code

## Nettoyage final : bilan (13:18) Décision du fondateur : « ne conserver que ce qui sert aux applications ». Ce commentaire ne cite aucun identifiant : les volumes y sont désignés par leur application. ### Méthode, étapes 2 et 3 Script par copie, avec les preuves relevées juste avant chaque geste : | Preuve | Contrôle | |---|---| | V | Le volume vivant est `attached/healthy`, avec **toutes** ses répliques `running` (3/3, autant que voulu). Toutes sont en mode `RW` dans le moteur, et aucune reconstruction n'est en cours. | | R | Aucun objet `replicas.longhorn.io` n'a `spec.dataDirectoryName` égal au nom exact du dossier. Pour les `.empty`, on compare aussi au nom sans ce suffixe. | | C | La ressource orphan désigne bien ce nœud et ce dossier. | | F | Sur le nœud : `lsof`, `fuser` et `ps` ne montrent rien, et la taille est relevée. | **Déroulé par volume** : 1. Toutes les copies du volume passent d'abord **à blanc**. Si une seule preuve manque, **aucune copie du volume n'est touchée**. 2. Les copies sont ensuite supprimées **une à une**, par la ressource orphan de l'API Longhorn. 3. Après chaque suppression, on vérifie que la ressource et le dossier ont disparu **et que le volume est toujours sain**. **Sabotage de l'instrument, avant usage** : lancé sur le dossier **actif** de la réplique de ClickHouse sur pi1, le script a refusé sur R, C et F (`lsof` 5 lignes, `fuser` 4 pids, 1 processus), code **10**, sans aucun geste. ### 1. Ce qui a été supprimé **Étape 1 : les 3 volumes orphelins** (anciens redis, alertmanager, prometheus-server), supprimés par l'API Longhorn. Longhorn a effacé lui-même leurs dossiers. | | pi1 | pi2 | pi3 | |---|---|---|---| | ancien redis | 51 Mo | 51 Mo | 51 Mo | | ancien alertmanager | 98 Mo | 98 Mo | 98 Mo | | ancien prometheus-server | 7 445 Mo | 7 445 Mo | 7 445 Mo | | **Sous-total** | **7 594 Mo** | **7 594 Mo** | **7 594 Mo** | **Étape 2 : les 23 anciennes copies de volumes vivants.** 23 sur 23 : preuves vraies, HTTP 200, vérifiées, volume toujours sain après chaque suppression. | Application | pi1 | pi2 | pi3 | |---|---|---|---| | prometheus-server | 7 915 Mo (1) | — | — | | crowdsec (config) | 16 Mo (1) | — | — | | ClickHouse | — | 1 544 Mo (1) | 3 976 Mo (3) | | Vault (audit) | — | 229 Mo (1) | 687 Mo (3) | | ERP | — | 1 087 Mo (1) | 3 153 Mo (3) | | Vault (données) | — | 521 Mo (1) | 1 386 Mo (3) | | url-shortener | — | — | 30 Mo (1) | | sauvegardes Longhorn (`backups-rwx`) | — | 7 733 Mo (1) | 18 677 Mo (3) | | **Sous-total** | **7 931 Mo** | **11 114 Mo** | **27 909 Mo** | **Total supprimé par ce nettoyage** : | pi1 | pi2 | pi3 | Total | |---|---|---|---| | **15 525 Mo** | **18 708 Mo** | **35 503 Mo** | **69 736 Mo** | S'y ajoutent les 17 dossiers des volumes disparus supprimés plus tôt : pi2 492 Mo, pi3 21 487 Mo. ### 2. Ce qui a été gardé, et pourquoi - **Les 48 répliques actives** des 16 volumes des applications : toutes `running`. - **Les deux dossiers `.empty` d'url-shortener** (pi2 et pi3, environ 1 Mo sur disque chacun), **non supprimés**. - Sur pi2, le nom de ce dossier, **sans le suffixe `.empty`**, est exactement le dossier de données de la réplique **active** du volume. - Aucune réplique ne pointe vers le nom exact du `.empty`. Mais cette parenté de nom est un fait qui contredit « aucune réplique ne le référence ». La règle « une preuve manque, on ne touche à aucune copie du volume » s'applique donc aux deux dossiers. - Ils datent du **2026-04-14**, le lendemain de la coupure de courant du 13/04 et de sa récupération (dépôt `factory`, outillage `recover`). - Leur sort attend un nouvel accord. ### 3. Espace libre sur les disques Longhorn | Nœud | `df` disponible avant (11:09Z) | après (11:17Z) | Gain | Disponible Longhorn avant → après | |---|---|---|---|---| | pi1 | 107 159 Mo | **122 663 Mo** | +15 504 Mo | 131 000 → 146 500 Mi | | pi2 | 227 582 Mo | **246 265 Mo** | +18 683 Mo | 251 400 → 270 100 Mi | | pi3 | 104 075 Mo | **139 550 Mo** | +35 475 Mo | 127 900 → 163 400 Mi | Sur la journée, avant l'étape 2b (10:57Z), pi3 n'avait que 82 623 Mo disponibles. Il en a désormais 139 550. ### 4. État des volumes (11:17Z) - **16 volumes, tous `attached/healthy`**, tous portés par une application : erp, erp-sandbox, traefik, backups-rwx, prospection, Vault ×2, ClickHouse, crowdsec ×2, MinIO, prometheus-server, redis, loki, alertmanager, url-shortener. - **48 répliques, toutes `running`**. **0 ressource orphan.** - **Cohérence disque ↔ Longhorn** : pi1 a 16 dossiers pour 16 répliques. pi2 et pi3 ont 17 dossiers pour 16 répliques, la différence étant le `.empty` gardé sur chacun. - Le délai de 20 s continue de s'appliquer au fil de l'eau, sans rattachement forcé. ### ⚠ Hors périmètre, constaté pendant le bilan : Plausible est retombé - Le pod `plausible` de la dernière révision (déclenchée à 10:46Z par la rotation de ses identifiants de base de données) tourne sur **pi2**. - Il a été disponible de 10:49 à 11:08Z. Depuis, il **boucle** : tué par sa sonde de vivacité (délai d'une seconde, pas de sonde de démarrage), code 137, environ 56 s après chaque départ, **sans une ligne de journal**. - ArgoCD affiche `plausible` en `Progressing`. - **ClickHouse n'est pas en cause** : 0 erreur d'E/S sur les 20 dernières minutes, et Plausible n'a pas de volume Longhorn. - La connexion à la base aboutit : pgbouncer voit les connexions s'ouvrir, puis se fermer à la mort du conteneur. - Cause non établie. Je n'ai rien fait : suivi dans tools#53. 🤖 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#52