# Signet: bitcoind crash puis blocage en chargement de wallet

**Date:** 2026-02-08  
**Auteur:** Équipe 4NK

## Problème

Bitcoind a planté silencieusement dans le conteneur `bitcoin-signet-instance` vers 3h08 du matin. Le conteneur reste actif, mais le processus bitcoind n'est plus en cours d'exécution. Au redémarrage du conteneur à 07:12, bitcoind est bloqué en chargement de wallet ("Loading wallet…").

### Symptômes

1. **Conteneur actif mais bitcoind planté** :
   - Le conteneur Docker est "Up" mais bitcoind n'est plus en cours d'exécution
   - `ps aux` dans le conteneur montre uniquement `entrypoint.sh`, `run.sh`, `mine.sh`, `tail -f /dev/null`
   - Pas de processus `bitcoind`

2. **RPC inaccessible** :
   - `bitcoin-cli` retourne : `Could not connect to the server 127.0.0.1:38332`
   - `curl` vers le RPC depuis l'hôte : connexion reset (exit 56)
   - Le port 38332 est toujours en écoute côté hôte (mapping Docker) mais il n'y a plus de processus RPC derrière

3. **Blocage en chargement de wallet** :
   - Après redémarrage, bitcoind est bloqué en "Loading wallet…"
   - `bitcoin-cli getblockchaininfo` retourne : `error code: -28 error message: Loading wallet…`
   - CPU à 100% mais aucun progrès visible
   - Wallet volumineux : 315MB (`wallet.dat`)

4. **Erreurs des services dépendants** :
   - Dashboard : erreurs "socket hang up" et "read ECONNRESET"
   - Script `sync-utxos-cron.sh` : erreurs de connexion RPC

### Impact

- **Fonctionnalité** : Tous les services dépendants de bitcoind sont hors service
- **Mining** : Le minage est arrêté
- **API** : L'API d'ancrage ne peut plus fonctionner
- **Dashboard** : Le dashboard ne peut plus afficher les données de la blockchain

## Root causes

1. **Crash silencieux de bitcoind** :
   - Bitcoind a planté silencieusement vers 3h08 sans message d'erreur dans les logs
   - Dernière activité normale : bloc miné à 02:54:29 (height 13139)
   - Nouveau bloc reçu à 03:08:48 (height 13140)
   - Après cela, plus aucune activité jusqu'au redémarrage à 07:12:16

2. **Wallet volumineux** :
   - Le wallet `custom_signet` fait 315MB
   - Le chargement du wallet peut prendre beaucoup de temps ou bloquer si le wallet est corrompu ou trop volumineux

3. **Absence de détection automatique** :
   - Le conteneur Docker reste actif même si bitcoind plante
   - Aucun mécanisme de redémarrage automatique de bitcoind dans le conteneur
   - Le script `check-services-status.sh` détecte le problème mais ne le corrige pas automatiquement

## Diagnostic

### Vérifier l'état actuel

1. **Vérifier les processus dans le conteneur** :
   ```bash
   docker exec bitcoin-signet-instance ps aux
   ```
   Si bitcoind n'apparaît pas, il a planté.

2. **Vérifier l'état du RPC** :
   ```bash
   docker exec bitcoin-signet-instance bitcoin-cli -datadir=/root/.bitcoin getblockchaininfo
   ```
   Si erreur "Could not connect" ou "Loading wallet…", bitcoind est planté ou bloqué.

3. **Vérifier les logs** :
   ```bash
   docker logs bitcoin-signet-instance --tail 100
   docker exec bitcoin-signet-instance tail -50 /root/.bitcoin/signet/debug.log
   ```

4. **Vérifier la taille du wallet** :
   ```bash
   docker exec bitcoin-signet-instance du -sh /root/.bitcoin/signet/wallets/custom_signet/
   ```

### Utiliser le script de diagnostic

```bash
./data/check-services-status.sh
```

Si "RPC: HORS SERVICE", bitcoind a planté.

## Correctifs

### Solution immédiate : Redémarrer le conteneur

```bash
docker restart bitcoin-signet-instance
```

Attendre 60-120 secondes que bitcoind démarre et charge le wallet, puis vérifier :

```bash
docker exec bitcoin-signet-instance bitcoin-cli -datadir=/root/.bitcoin getblockchaininfo
```

### Si le wallet reste bloqué en chargement

Si après redémarrage, bitcoind reste bloqué en "Loading wallet…" pendant plus de 5 minutes :

1. **Arrêter le conteneur** :
   ```bash
   docker stop bitcoin-signet-instance
   ```

2. **Vérifier l'intégrité du wallet** :
   ```bash
   docker exec bitcoin-signet-instance ls -lah /root/.bitcoin/signet/wallets/custom_signet/
   ```
   Vérifier la présence de `wallet.dat-journal` (fichier de journalisation)

3. **Redémarrer avec vérification** :
   ```bash
   docker start bitcoin-signet-instance
   docker logs bitcoin-signet-instance -f
   ```
   Surveiller les logs pour voir si le wallet se charge correctement.

4. **Si le wallet est corrompu** :
   - Sauvegarder le wallet actuel
   - Essayer de réparer avec `bitcoin-wallet` (si disponible)
   - Ou restaurer depuis une sauvegarde

### Solution préventive : Améliorer la détection et le redémarrage automatique

1. **Améliorer le script `check-services-status.sh`** :
   - Détecter si bitcoind est planté même si le conteneur est actif
   - Proposer automatiquement un redémarrage si le problème est détecté

2. **Ajouter un healthcheck Docker** :
   - Créer un healthcheck qui vérifie que le RPC bitcoind répond
   - Configurer Docker pour redémarrer automatiquement le conteneur si le healthcheck échoue

3. **Surveillance proactive** :
   - Ajouter un cron job qui exécute `check-services-status.sh` toutes les 5 minutes
   - Envoyer une alerte si bitcoind est hors service

## Prévention / suivi

- **Surveillance régulière** : Exécuter `./data/check-services-status.sh` régulièrement (ou via cron toutes les 5 minutes)
- **Logs** : Surveiller les logs bitcoind pour détecter les problèmes avant qu'ils ne causent un crash
- **Sauvegardes** : Sauvegarder régulièrement le wallet et la chaîne
- **Investigation** : En cas de répétition des crashes, investiguer (RAM, disque, `dmesg` OOM, logs bitcoind complets)

## Note importante sur les crons et la cause probable

**Le script `restart-services-cron.sh` n'est PAS actuellement dans les crontabs.**

**Cause probable du crash récurrent vers 3h** : Le script `sync-utxos-cron.sh` s'exécute à 3h00 et fait un appel RPC très lourd (`listunspent` avec `maximumCount: 9999999`). Avec un wallet volumineux (315MB) et potentiellement des centaines de milliers d'UTXOs, cet appel peut :
- Consommer beaucoup de mémoire
- Prendre beaucoup de temps
- Causer un crash de bitcoind si la mémoire est insuffisante ou si bitcoind est déjà dans un état fragile

**Recommandation pour ajouter `restart-services-cron.sh` à 4h** :

✅ **OUI, c'est prudent d'ajouter `restart-services-cron.sh` à 4h**, car :
- Le script a été amélioré pour gérer les wallets volumineux (timeout de 5 minutes, détection du chargement de wallet)
- Cela permettra de redémarrer bitcoind automatiquement après un crash potentiel vers 3h
- Le redémarrage à 4h laisse le temps au script `sync-utxos-cron.sh` de se terminer (ou d'échouer) avant le redémarrage

⚠️ **Mais il faut aussi** :
- Surveiller les logs pour confirmer que le crash est bien lié au script `sync-utxos-cron.sh`
- Considérer d'optimiser le script `sync-utxos-spent-status.mjs` pour réduire la charge sur bitcoind
- Surveiller la mémoire disponible pour bitcoind

**Configuration recommandée** :
```bash
# Ajouter dans crontab
0 4 * * * /home/ncantu/Bureau/code/bitcoin/data/restart-services-cron.sh
```

Cela redémarrera bitcoind tous les jours à 4h, ce qui permettra de récupérer automatiquement après un crash potentiel vers 3h.

## Pages affectées

- `data/check-services-status.sh` (script de vérification)
- `fixKnowledge/signet-bitcoind-crash-wallet-loading-stuck.md` (ce document)
- `fixKnowledge/signet-bitcoind-crash-mining-stopped.md` (documentation similaire)