mirror of
https://github.com/Alkatrazz24/Funk-lab.git
synced 2026-07-09 01:24:42 +02:00
763b29495e
- incidents.md : incident corruption EXT4 après arrêt brutal (655 erreurs, e2fsck, réinstall hermes-agent, nouveau chemin /opt/hermes/.hermes/) - hermes.md : arborescence mise à jour (code SSD vs données RAID5), chemins pip/venv/frontend corrigés - Ansible role hermes_agent : venv path et wrapper mis à jour (hermes_home/.hermes/hermes-agent/venv/ au lieu de hermes_data_dir/) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
190 lines
6.2 KiB
Markdown
190 lines
6.2 KiB
Markdown
# Incidents — Historique et résolutions
|
|
|
|
---
|
|
|
|
## 2026-05-13 — storage-01 : corruption EXT4 après arrêt brutal + reinstall hermes-agent
|
|
|
|
### Symptômes
|
|
|
|
- `hermes-agent` en boucle de crash : `SyntaxError: source code string cannot contain null bytes`
|
|
- Erreurs EXT4 au démarrage des services : `Directory block failed checksum`, `deleted inode referenced`
|
|
- `dmesg` : `EXT4-fs (md0): error count since last fsck: 655`
|
|
- `sdb` : erreurs ATA bus (`SError: { RecovComm HostInt PHYRdyChg PHYInt }`) et I/O error sector 13405184
|
|
|
|
### Cause racine
|
|
|
|
Arrêt brutal du cluster la veille (`funk-stop --k8s`) → journal ext4 non rejoué correctement → 655 erreurs de corruption sur `/dev/md0`. `sdb` avait des erreurs transitoires mais SMART PASSED (pas de défaillance matérielle).
|
|
|
|
### Résolution étape par étape
|
|
|
|
**1. Vérifier SMART sdb**
|
|
|
|
```bash
|
|
smartctl -H /dev/sdb
|
|
# SMART overall-health self-assessment test result: PASSED → purement logiciel
|
|
```
|
|
|
|
**2. Arrêter les services et démonter**
|
|
|
|
```bash
|
|
sudo systemctl stop hermes-agent litellm qdrant postgresql-16 nfs-server
|
|
sudo umount /srv/data
|
|
```
|
|
|
|
**3. Réparer le filesystem**
|
|
|
|
```bash
|
|
sudo e2fsck -f -y /dev/md0
|
|
# 655 erreurs corrigées : HTREE invalides, blocs multiplement revendiqués,
|
|
# checksums de répertoires incorrects, compteurs d'inodes wronge
|
|
```
|
|
|
|
**4. Remonter et redémarrer les services**
|
|
|
|
```bash
|
|
sudo mount /srv/data
|
|
sudo systemctl start postgresql-16 qdrant litellm hermes-agent nfs-server
|
|
```
|
|
|
|
**5. Hermes-agent toujours en erreur après fsck**
|
|
|
|
Le e2fsck a zéroïsé des blocs appartenant à plusieurs inodes simultanément → des fichiers du venv Python et du code source `hermes_cli/` ont été corrompus (null bytes).
|
|
|
|
Tentatives de réparation du venv échouées (`pip install -e .` crash, `uv.lock` corrompu).
|
|
|
|
**6. Réinstallation complète de hermes-agent**
|
|
|
|
```bash
|
|
# Supprimer le code source corrompu (les profils dans /srv/data/hermes/profiles/ ne sont PAS touchés)
|
|
sudo rm -rf /srv/data/hermes/hermes-agent
|
|
sudo rm /opt/hermes/.local/bin/hermes
|
|
|
|
# Réinstaller depuis le script officiel (depuis un répertoire valide)
|
|
cd /srv/data/hermes
|
|
sudo -u hermes bash -c 'cd /srv/data/hermes && HOME=/opt/hermes HERMES_HOME=/srv/data/hermes curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash'
|
|
```
|
|
|
|
> Lors du `sudo rm -rf`, ne pas rester dans le répertoire supprimé — le shell perd le CWD et le script d'installation échoue avec `getcwd: cannot access parent directories`.
|
|
|
|
**Résultat** : hermes-agent réinstallé dans `/opt/hermes/.hermes/hermes-agent/` (SSD OS, plus de RAID5). Tous les profils (`funk-ai`, `brain`, `system`, `monitor`) intacts dans `/srv/data/hermes/profiles/`.
|
|
|
|
### Changement d'architecture post-incident
|
|
|
|
| Avant | Après |
|
|
|---|---|
|
|
| Code hermes-agent : `/srv/data/hermes/hermes-agent/` (RAID5) | Code hermes-agent : `/opt/hermes/.hermes/hermes-agent/` (SSD OS) |
|
|
| Venv : `/srv/data/hermes/hermes-agent/venv/` | Venv : `/opt/hermes/.hermes/hermes-agent/venv/` |
|
|
| Profils/données : `/srv/data/hermes/` | Profils/données : `/srv/data/hermes/` (inchangé) |
|
|
|
|
Le code étant désormais sur le SSD, une corruption future du RAID5 n'impactera plus l'installation — seulement les profils et données.
|
|
|
|
### Surveillance post-incident
|
|
|
|
```bash
|
|
# Santé RAID et disques
|
|
cat /proc/mdstat
|
|
smartctl -H /dev/sdb # à surveiller
|
|
|
|
# Vérifier que e2fsck n'a pas schedulé un check au prochain boot
|
|
sudo tune2fs -l /dev/md0 | grep -E "check|count|error"
|
|
```
|
|
|
|
---
|
|
|
|
## 2026-05-11 — storage-01 : boucle fsck après coupure de courant
|
|
|
|
### Symptômes
|
|
|
|
- Boucle infinie de `fsck` au démarrage sur `/dev/md0`
|
|
- `You are in emergency mode. Give root password for maintenance` — mot de passe impossible à saisir (messages défilants)
|
|
- Après résolution : `hermes-agent` en boucle d'erreurs (cause : `/srv/data` non monté)
|
|
|
|
### Architecture concernée
|
|
|
|
| Composant | Détail |
|
|
|---|---|
|
|
| Disque système | NVMe `nvme0n1` — LVM (`almalinux-root` XFS 70G, swap 14.7G, home 845G) |
|
|
| RAID données | RAID5 software `md0` — 4 disques SATA 931.5G (`sda1`, `sdb2`, `sdc1`, `sdd1`) |
|
|
| Point de montage | `/srv/data` (ext4) |
|
|
|
|
### Cause racine
|
|
|
|
La coupure de courant a corrompu le système de fichiers **XFS** sur `almalinux-root`. Au redémarrage, systemd tentait de vérifier `/srv/data` avant que le RAID `md0` soit assemblé → boucle bloquante.
|
|
|
|
### Résolution étape par étape
|
|
|
|
**1. Shell de secours via GRUB**
|
|
|
|
Au démarrage, appuyer sur `Shift` pour afficher le menu GRUB. Appuyer sur `e` pour éditer la ligne `linux` :
|
|
- Remplacer `ro` par `rw`
|
|
- Ajouter `init=/bin/bash` en fin de ligne
|
|
|
|
Démarrer avec `Ctrl+X`.
|
|
|
|
**2. Activer le LVM**
|
|
|
|
```bash
|
|
lvm vgchange -ay
|
|
# 3 logical volume(s) in volume group "almalinux" now active
|
|
```
|
|
|
|
**3. Réparer le XFS (pas fsck)**
|
|
|
|
XFS nécessite `xfs_repair`, pas `fsck` :
|
|
|
|
```bash
|
|
umount /dev/mapper/almalinux-root
|
|
xfs_repair /dev/mapper/almalinux-root
|
|
# Phases 1 à 7 — succès
|
|
```
|
|
|
|
**4. Désactiver temporairement `/srv/data` dans fstab**
|
|
|
|
```bash
|
|
vi /etc/fstab
|
|
# Commenter la ligne /srv/data pour permettre le boot sans RAID
|
|
```
|
|
|
|
**5. Reboot** → système normal, RAID intact `[4/4] [UUUU]`.
|
|
|
|
### Fix permanent — fstab
|
|
|
|
Modifier la ligne `/srv/data` dans `/etc/fstab` :
|
|
|
|
```
|
|
# Avant
|
|
UUID=3add8360-fa01-47eb-0aa1-0e84bacbbc15 /srv/data ext4 defaults,noatime,nodiratime 0 2
|
|
|
|
# Après
|
|
UUID=3add8360-fa01-47eb-0aa1-0e84bacbbc15 /srv/data ext4 defaults,noatime,nodiratime,_netdev 0 0
|
|
```
|
|
|
|
| Changement | Effet |
|
|
|---|---|
|
|
| `0 2` → `0 0` | Désactive la vérification fsck automatique au boot |
|
|
| `_netdev` | Force systemd à attendre que tous les périphériques (RAID) soient prêts avant de monter |
|
|
|
|
### Surveillance post-incident
|
|
|
|
```bash
|
|
# État du RAID
|
|
cat /proc/mdstat
|
|
|
|
# Santé des disques (sdb a généré des erreurs I/O — à surveiller)
|
|
smartctl -a /dev/sda
|
|
smartctl -a /dev/sdb
|
|
smartctl -a /dev/sdc
|
|
smartctl -a /dev/sdd
|
|
|
|
# Monter /srv/data manuellement si besoin
|
|
mount /srv/data
|
|
|
|
# Logs de boot
|
|
journalctl -xb | grep -i "error\|fail"
|
|
```
|
|
|
|
### Points d'attention
|
|
|
|
- `sdb` a généré des erreurs I/O pendant l'incident — il est revenu opérationnel mais doit être surveillé régulièrement avec `smartctl`.
|
|
- Envisager un **onduleur (UPS)** pour prévenir ce type d'incident sur coupure de courant.
|
|
- Le fix fstab (`_netdev`, `0 0`) est permanent — ne pas revenir aux valeurs précédentes.
|