🇬🇧 English · 🇫🇷 Français

S'applique à Hydranos 4.4.

Cette page est pour vous si vous faites tourner Hydranos 3.x (qui s'appelait alors Hydra) et voulez passer en 4.4 sans perdre de torrents, de temps de seed ni votre réputation auprès des trackers. À la fin, vous saurez ce qui a disparu, ce qui le remplace, quoi sauvegarder, ce que le premier démarrage de la 4.4 fait à vos fichiers, et pourquoi il n'y a pas de retour possible en dehors de votre sauvegarde.

C'est la seule page de ce wiki qui explique la 3.x. Les mots « agent », « front », « gRPC » et « processus Typhon » désignent des choses qui n'existent pas en 4.4 ; les autres pages ne les mentionnent que pour dire qu'elles ont disparu.

En bref : la 3.x, c'était deux programmes (un démon Go et un moteur Rust qui se parlaient par un socket local), éventuellement répartis sur plusieurs machines avec des « agents » gRPC. La 4.4, c'est un seul processus Rust, hydranos, qui contient l'interface web, les API et tous les moteurs. Plusieurs machines, ce sont désormais plusieurs instances complètes qui se parlent par leur API HTTP normale.

flowchart LR
  subgraph v3["3.x (disparue)"]
    direction TB
    GO["hydra (démon Go, le front)"]
    SOCK(["socket unix local, JSON-RPC"])
    ENG["processus moteur Typhon"]
    AG["hôte agent distant"]
    GO --- SOCK --- ENG
    GO -- "gRPC + jeton d'agent" --- AG
  end
  subgraph v4["4.4"]
    direction TB
    subgraph P["un seul processus hydranos"]
      UI["interface web, API REST, shim qBittorrent, MCP"]
      R["moteur race"]
      H["moteur hoard"]
      X["moteurs supplémentaires, facultatifs"]
    end
    N["autre instance Hydranos (nœud)"]
    P -- "HTTP + la clé API du nœud" --> N
  end

Certains noms de fichiers n'ont pas changé : la config s'appelle toujours default.toml, le store est toujours <data_dir>/hydra.db, et le fichier de statistiques est toujours <data_dir>/bench.db.

La 4.4 lit votre default.toml existant, votre hydra.db existant et vos dossiers de moteurs existants. Rien n'est à convertir à la main. Mais le premier démarrage réécrit certains d'entre eux, et cette réécriture est irréversible.

Il n'y a pas de retour arrière automatique. Dès que la 4.3.0 ou une version ultérieure a ouvert le store, elle reconstruit la table torrents sur une nouvelle clé (une ligne par torrent et par moteur). Un binaire 3.x suppose une ligne par info hash et ne doit plus jamais être lancé sur ce fichier. Restaurer votre sauvegarde est le seul moyen de revenir à la 3.x.

Arrêtez d'abord la 3.x proprement (pour que ses données de reprise soient écrites), puis copiez :

Dans l'image Docker, le dossier de configuration et data_dir sont tous deux /config : copier tout le volume /config, conteneur arrêté, couvre donc l'ensemble. Vos données de contenu ne sont pas touchées par la mise à jour.

Exemple (Docker, conteneur arrêté) :

docker stop -t 300 hydra
tar -C /srv/hydra -czf hydra-3x-backup-$(date +%F).tar.gz config

Vérifiez aussi, avant de lancer la 4.4 :

• data_dir pointe vers votre store existant. Sinon, la 4.4 y crée un hydra.db neuf et vide, et vous voyez une instance vide.
• Les dossiers des moteurs sont à côté de default.toml. La 4.4 cherche <config dir>/<engine id>/ (la même disposition que celle qu'écrit la 3.x). S'ils sont ailleurs, les torrents reviennent sans état de reprise et doivent être revérifiés.

flowchart TD
  A["Arrêter la 3.x proprement"] --> B["Sauvegarder default.toml, hydra.db, bench.db,<br/>dossiers des moteurs, uploads/"]
  B --> C["Changer d'image ou de binaire, renommer les variables HYDRA_,<br/>retirer les options propres à la 3.x"]
  C --> D["Premier démarrage 4.4 : les migrations s'exécutent"]
  D --> E{"Lignes de journal attendues ?<br/>Torrents listés ?"}
  E -- "oui" --> F["Checklist, puis terminé"]
  E -- "non" --> G["Arrêter la 4.4"]
  G --> H["Restaurer la sauvegarde"]
  H --> I["Relancer la 3.x"]

Vous pouvez passer directement à la 4.4 : à son premier démarrage, elle exécute toutes les migrations du store qu'elle connaît (elles sont cumulatives), aucune version 4.x intermédiaire n'est donc nécessaire. Ne visez pas les versions 4.1.0 à 4.1.4 (voir Versions à éviter).

1. Changez l'image pour ghcr.io/kheopsian/hydranos:v4.4.1 (épinglez le tag). L'ancien chemin ghcr.io/kheopsian/hydra est obsolète : ne l'utilisez pas pour la 4.x, pas même son tag latest. Il ne contient que des images publiées avant le renommage de la 4.1.0, et le nettoyage par rétention peut en avoir supprimé beaucoup : n'y épinglez un tag 3.x (pour un retour arrière) qu'après avoir vérifié qu'il existe encore ; la 4.1.0 et les suivantes ne sont que sous ghcr.io/kheopsian/hydranos.
2. Renommez chaque variable HYDRA_* en HYDRANOS_*. Par exemple, HYDRA_STOP_TIMEOUT devient HYDRANOS_STOP_TIMEOUT.
3. Retirez tout command: qui portait des options 3.x (--agent-only, --front-only, --agent-addr…). La 4.4 ne les honore pas : chaque option --agent-… ou --front-… est nommée sur stderr (hydranos: ignoring --agent-only: the agent/front split was removed in 4.x and Hydranos now runs as one process. Starting a normal instance. …, avec la commande d'enrôlement de nœud), les valeurs de --agent-addr, --agent-token, --agent-tls-cert, --agent-tls-key et --front-addr sont sautées, et le processus démarre comme une instance complète avec ses propres moteurs race et hoard. Tout autre argument inconnu reçoit hydranos: ignoring unknown argument "…"; starting anyway (see hydranos --help).
4. Retirez HYDRANOS_ENGINE_ID et HYDRANOS_ENGINES de l'environnement. L'entrypoint les refuse : il affiche hydranos: ignoring HYDRANOS_ENGINE_ID: the 3.x agent mode was removed in 4.x and Hydranos now runs as one process. Starting a normal instance on /config/default.toml. … (le dossier est HYDRANOS_CONFIG_DIR), vous invite à enrôler plutôt la machine comme nœud, et démarre sur cette config comme d'habitude. Retirer les variables fait taire le message.
5. Laissez assez de temps à l'arrêt. HYDRANOS_STOP_TIMEOUT borne l'écriture de reprise (120 par défaut ; aussi 90s, 2m, 1m30s, voir Exploiter Hydranos) ; le compose de référence utilise stop_grace_period: 150s. Gardez le délai de grâce au-dessus du timeout plus environ 10 s.
6. Gardez les mêmes volumes. Les noms de conteneur et de service sont à votre choix ; garder hydra fonctionne.

Dans un fichier compose 3.x, seules ces lignes changent :

    image: ghcr.io/kheopsian/hydranos:v4.4.1   # avant : ghcr.io/kheopsian/hydra:<3.x tag>
    stop_grace_period: 150s
    # environment : chaque HYDRA_* renommée en HYDRANOS_* ; HYDRANOS_ENGINE_ID / HYDRANOS_ENGINES retirées
    # command : aucune option 3.x (--agent-only, --front-only, --agent-addr...)

Les ports et les volumes restent tels quels. Le fichier compose complet, avec chaque option expliquée, est sur Docker.

L'installeur bare metal de la 3.x (à partir de la 3.8.0) utilisait /opt/hydra, /etc/hydra, /var/lib/hydra, un utilisateur hydra et une unité hydra. Le install.sh de la 4.4 utilise /opt/hydranos, /etc/hydranos, /var/lib/hydranos, l'utilisateur hydranos et une unité hydranos. Il ne crée une nouvelle config que si /etc/hydranos/default.toml n'existe pas, donc mettez d'abord vos anciens fichiers en place :

sudo systemctl stop hydra
sudo systemctl disable hydra
# Sauvegardez d'abord (voir plus haut), puis déplacez la config + les dossiers des moteurs et le dossier de données
sudo mkdir -p /etc/hydranos /var/lib/hydranos
sudo cp -a /etc/hydra/. /etc/hydranos/
sudo cp -a /var/lib/hydra/. /var/lib/hydranos/
# Faire pointer data_dir vers le nouvel emplacement
sudo sed -i 's#^data_dir = .*#data_dir = "/var/lib/hydranos"#' /etc/hydranos/default.toml
# Créer le nouveau compte maintenant, pour que les fichiers lui appartiennent avant le démarrage du service
sudo useradd --system --home-dir /var/lib/hydranos --shell /usr/sbin/nologin hydranos
sudo chown -R hydranos:hydranos /etc/hydranos /var/lib/hydranos
# Décompressez l'archive 4.4.0, puis depuis son dossier :
sudo ./install.sh

install.sh réutilise le compte hydranos et la config existants, installe hydranos et hydranos-update dans /opt/hydranos, installe l'unité (ou, si /etc/systemd/system/hydranos.service existe déjà et diffère, garde la vôtre et pose celle fournie à côté sous le nom hydranos.service.new), puis active et démarre le service. Renommez en HYDRANOS_* toute variable HYDRA_* des unités drop-in. Les détails de l'unité sont sur Linux (bare metal).

1. Arrêtez le démon 3.x.
2. Sauvegardez son default.toml, son dossier de données et ses dossiers de moteurs.
3. Décompressez hydranos-v4.4.0-windows-amd64.zip et lancez hydranos.exe avec un chemin de config explicite, pour qu'il utilise vos fichiers existants au lieu d'en créer de nouveaux :

   hydranos.exe --config C:\Hydranos\default.toml
   

4. Arrêtez-le avec le menu de l'icône de notification Quit Hydranos, qui écrit les données de reprise ; attendez que hydranos.exe ait disparu du Gestionnaire des tâches.

Sans --config, la 4.4 sous Windows utilise le default.toml à côté de hydranos.exe ou, s'il n'y en a pas, le \config\default.toml laissé par une installation 4.3. L'avis qu'elle affiche (hydranos: using … (the 4.3 location); move it beside hydranos.exe or pass --config) est écrit avant qu'une console soit attachée : il n'apparaît donc pas dans une fenêtre de console. Voir Windows.

Dans l'ordre, le premier démarrage fait ce qui suit. Les lignes de journal citées sont celles à chercher (dans hydranos.log à côté de la config, et dans tous les cas dans docker logs ou journalctl).

1. Clé API. Si [daemon] api_key est vide, une nouvelle clé (48 caractères hexadécimaux) est générée et écrite dans la config, avec la ligne de journal no API key was configured; a new one has been generated and written to the config. Si c'est encore la valeur d'exemple publiée change-me-in-production, elle est remplacée de la même façon et la ligne est the configured API key was the published placeholder and has been replaced by a generated one -- clients configured with the old value must be updated …. Tout client qui utilisait l'ancienne valeur doit recevoir la nouvelle clé.

2. Clés 3.x nommées. Chaque clé que Hydranos sait morte reçoit un avertissement, config: <where> is ignored: <why>. Instead: <what to do>., à ce démarrage et à chacun des suivants : [daemon] agent_token ; dans les blocs agent/engine, addr (s'il n'est pas vide), token, tls_ca et la sous-table engine ; listen_interfaces, file_pool_size, custom_choking et disk_slots dans [race], [hoard] ou la session d'un bloc ; les sections [bench], [metrics], [peer_intel], [arr_cleanup], [notify] ; et [race_drain] min_age_minutes. Par exemple, pour un bloc agent nommé box2 (la ligne nomme le bloc tel qu'il est écrit dans le TOML, type et nom) :

   config: [[agent]] "box2" addr is ignored: a 3.x remote agent: 4.x has no agent channel, so this block starts nothing here and reaches nothing there. Instead: enrol that machine as a node: …
   

   Une fois le store ouvert, les champs de catégorie 3.x reçoivent une ligne par champ, qui nomme les catégories : config: category field `strategy` (in films, series) is ignored: …. Ce sont des avertissements, jamais des erreurs ; la liste complète est sous Restes plus bas. Une faute de frappe dans un nom de clé est toujours acceptée sans un mot.

3. Nouvelle clé de table, nouvelles tables, WAL. Quand le premier moteur ouvre le store, la table torrents est reconstruite sur (info_hash, session) en une seule transaction : re-keying the torrents table on (info_hash, session); this rewrites it and ends the 3.x rollback. De nouvelles tables (nœuds, workflows, magnets, bans d'IP…) sont ajoutées, et le store passe en journalisation WAL, sauf si son dossier est sur un système de fichiers réseau.

4. Metainfo. Pour chaque moteur, tout torrent connu de son state.db dont le .torrent manque dans le store est importé depuis <data_dir>/uploads/<info_hash>.torrent (seulement les fichiers nommés d'après leur hash, et seulement si le hash correspond) : metainfo migrated out of uploads/ and into the store. Sur une installation dont l'état de reprise était encore en JSON (avant 3.94.0), state.db est vide à ce moment-là, donc cet import a lieu au deuxième démarrage.

5. État de reprise (avant 3.94.0 uniquement). Par moteur, l'ancien JSON de resume/ est importé une fois dans un state.db vide : [statedb] first start on SQLite state: N records carried over.

6. bench.db. Ouvert après les moteurs, et passé en WAL avec la même exception pour les systèmes de fichiers réseau.

7. Torrents arrêtés. Les torrents que vous aviez arrêtés en 3.x restent arrêtés.

8. Suppression de l'usurpation de client. Seuls les torrents dont le premier tracker correspondait à une surcharge [announce_clients] sont arrêtés, une seule fois ; un avertissement liste les hôtes et le nombre (client spoofing has been removed from Hydranos. These torrents were announcing as another client …). Les tables sont ensuite retirées de default.toml. Quand vous redémarrez ces torrents, ils annoncent avec le peer id propre à Hydranos : vérifiez d'abord que chaque tracker autorise Hydranos. Rien d'autre n'est arrêté.

9. Travail en arrière-plan. Un index de contenu est construit dans un thread d'arrière-plan, et bench.db reçoit un index et regroupe les échantillons par tracker de plus de 48 h en lignes de 5 minutes. L'interface reste utilisable pendant ce temps.

Si le store ne peut pas être ouvert, ou s'il lui manque une colonne dont la 4.4 a besoin, le démon ne devine pas : il journalise the store could not be opened: <why> -- starting in rescue mode et démarre en mode de secours à son adresse habituelle (api_host, api_port). L'interface web n'est pas servie : / répond par le texte d'une ligne hydra: the store could not be opened (voir Mode de secours sur Exploiter Hydranos). Arrêtez-le, restaurez votre sauvegarde, et signalez le message sur le suivi des problèmes.

Votre mot de passe admin continue de fonctionner : le format du hash [auth] n'a pas changé. Si [auth] password_hash est vide, l'interface affiche l'écran de premier démarrage Bienvenue dans Hydranos (Welcome to Hydranos) avec Créer le compte (Create account). Cet écran ne répond qu'à un appelant en boucle locale ou sur un réseau privé ; d'ailleurs, définissez le mot de passe sur l'hôte avec hydranos reset-password (voir Sécurité & accès).

• hydranos --version affiche la version que vous avez installée (hydranos 4.x.y).
• Le journal montre les lignes ci-dessus, et l'interface web s'ouvre normalement (le mode de secours ne sert aucune interface).
• Chaque ligne config: … is ignored lue, et chaque clé nommée retirée de default.toml (votre sauvegarde garde le fichier 3.x ; les champs de catégorie restent dans le store et continuent d'être nommés).
• Les onglets Race et Hoard listent vos torrents ; le nombre correspond à celui de la 3.x.
• Torrents arrêtés par la migration de l'usurpation passés en revue, puis démarrés avec Démarrer (Start) là où le tracker l'autorise.
• Sonarr, Radarr, autobrr et les scripts utilisent la clé API actuelle ([daemon] api_key).
• Anciens hôtes agents 3.x rajoutés comme nœuds : onglet Nodes, + Declare an existing one (URL + clé API de cette instance) ou + Enrol a machine. Voir Nœuds & plusieurs machines.
• Les trackers listés avec des URL udp:// sont désormais annoncés ; tant que les annonces d'un moteur passent par un proxy SOCKS5 (announce_proxy, le mode SOCKS5 ou TYPHON_ANNOUNCE_PROXY), ses trackers UDP ne sont pas annoncés (voir VPN & sortie réseau).
• Catégories qui dépendaient d'une stratégie de routage ou de chemins par agent : revérifiez leur Mode et leur chemin de sauvegarde.
• Le délai d'arrêt de votre superviseur (stop_grace_period, TimeoutStopSec) est suffisant.
• Gardez la sauvegarde 3.x jusqu'à être sûr de vous ; c'est votre seul moyen de revenir en arrière.

La 4.4 ne convertit pas un agent 3.x en nœud. Chaque machine devient sa propre instance avec son propre store, et l'instance où vous la déclarez (le contrôleur) voit ses torrents dans la liste fusionnée. Il n'y a pas de transfert automatique des torrents qu'un agent 3.x faisait tourner vers une instance 4.4 sur cette machine : prévoyez de les y ajouter à nouveau, en pointant vers les données existantes (voir Ajouter des torrents & données existantes). Quel déploiement convient à quel besoin est expliqué sur Topologies de déploiement.

Plusieurs tunnels VPN sur une même machine n'ont plus besoin d'agents : déclarez un moteur supplémentaire par tunnel (+ Add an engine dans l'onglet Nodes) et, sous Linux, laissez Hydranos monter chaque tunnel (WireGuard géré) ou épinglez chaque moteur à une interface que vous gérez. Lisez ce qu'une interface épingle sur VPN & sortie réseau.

Ces éléments survivent dans d'anciens fichiers de configuration, scripts et fichiers compose. La 4.4 nomme la plupart d'entre eux au lieu de les ignorer en silence. Ne comptez sur aucun d'eux.

Accepté mais ignoré en 4.4 : les réglages d'agent distant de la 3.x — blocs agent (tableau de tables TOML) avec un addr (et leurs token, tls_ca), et [daemon] agent_token — sont lus puis jamais utilisés, et chacun est nommé dans un avertissement au démarrage ; aucune connexion n'est établie — déclarez plutôt la machine distante comme nœud.

Un bloc agent ou engine sans addr et avec un role démarre toujours un moteur supplémentaire local : agent est un ancien nom du même bloc (voir Config : moteurs & drain race). Avec un addr, comme dans cet exemple 3.x, il est ignoré :

# agent distant 3.x : ignoré en 4.4, ne démarre rien, nommé au démarrage
[[agent]]
name = "box2"
addr = "192.0.2.10:7070"

L'API d'agents distants de la 3.x a disparu : toute méthode sous /api/agents et /api/jobs/move-remote répond 410 Gone (derrière la clé API, donc 401 sans elle), avec les routes à utiliser à la place :

{"error":"the 3.x agent API was removed in 4.4: engines on this machine are /api/engines, other machines are /api/nodes","see":["/api/engines","/api/nodes"]}

{"error":"move-remote was removed in 4.4: use POST /api/selection/handoff with a node from /api/nodes and one of its engines","see":["/api/selection/handoff","/api/nodes","/api/engines"]}

hydranos reset-password et hydranos hash-password existent de nouveau en 4.4 (voir Sécurité & accès).

Les documents de conception 3.x (docs/architecture-agent-front.md, docs/agentification-status.md, docs/hoard_announce_scheduler.md) ne sont plus dans le dépôt, et packaging/README-windows.md et l'unité fournie décrivent la 4.x. Deux commentaires de configs/default.toml sont périmés : « every agent it drives » (les tables d'annonce), et generate with: hydra hash-password (la commande est hydranos hash-password). Les clés 4.4 qui ne font rien sont listées sur Configuration : vue d'ensemble ; toutes les lacunes connues sont sur Limites connues de la 4.4.

• 4.1.0 à 4.1.4 ont été retirées : leur image s'arrête immédiatement (le binaire à l'intérieur était mal nommé) et les 4.1.0 à 4.1.3 n'ont publié aucune archive. Elles ont disparu du registre et des releases. La première 4.1 fonctionnelle est la 4.1.5.
• 4.0.0 et 4.0.1 n'ont publié aucune archive de binaires.

Les numéros de version se lisent major.release.patch et ne suivent pas le versionnage sémantique : le majeur n'augmente que lorsque la mise à jour demande plus que le remplacement du binaire. Voir le CHANGELOG.

Depuis n'importe quelle 4.x fonctionnelle, passer en 4.4 revient à remplacer le binaire ou l'image sur la même config et le même store. Depuis la 4.0.x, le renommage de la 4.1.0 s'applique (chemin de l'image, variables d'environnement HYDRANOS_*, /opt/hydranos, nom de l'unité). Depuis la 4.2 ou plus ancienne, le premier démarrage passe le store et bench.db en WAL, construit un index d'historique des trackers sur bench.db et ajoute de nouvelles tables (la 4.3.0 le faisait ; la 4.4 exécute toutes les migrations qu'elle connaît). Les installations bare metal et Windows peuvent utiliser hydranos-update ; la procédure (et ses limites) est sur Exploiter Hydranos.

Changez le tag de l'image (ghcr.io/kheopsian/hydranos:v4.4.1) ou les binaires, puis démarrez. Le store ne fait que gagner des tables (rss_*, share_limits) et deux colonnes magnets ; votre config n'est pas réécrite. Une 4.3 sous Windows doit être quittée depuis la zone de notification avant que hydranos-update la remplace (elle ne répond pas à l'événement d'arrêt de la 4.4). Ce qui change pour un fichier écrit par la 4.3 :

• Test de ligne toutes les heures. Un default.toml créé par la 4.3.0 contient [vpn_speedtest] enabled = true, iperf3_server = "ping.online.net" et interval_secs = 3600. La 4.3 les ignorait ; la 4.4 les lit, et lance donc un test iperf3 (envoi puis réception, 10 s chacun) contre ce serveur public toutes les heures. Pour ne garder que le Lancer maintenant (Run now) manuel, mettez interval_secs = 0 à la main dans le fichier (les Paramètres avancés masquent cette clé en 4.4), ou enabled = false pour désactiver complètement le test. Toute valeur inférieure à 300 compte pour 300.
• Clés mortes nommées. Les clés qui ne font rien (listen_interfaces, [race.custom_choking], [bench], [metrics], [race_drain] min_age_minutes, blocs agent 3.x…) reçoivent désormais un avertissement config: … is ignored: …. Instead: …. à chaque démarrage (liste sous Restes plus haut). Rien ne casse ; supprimez-les pour alléger le journal.
• Valeurs par défaut des clés absentes. Une section [race]/[hoard] sans enable_dht, enable_pex ou enable_webseed les a désormais activés (4.3 : désactivés) ; le modèle 4.3 n'a pas d'enable_webseed, les webseeds commencent donc à être utilisés. Un listen_port absent vaut 16171 (race) ou 16172 (hoard), ou le suivant qu'aucun autre moteur n'utilise, au lieu d'un port aléatoire. Les peer_timeout = 30 (race) et 20 (hoard) du modèle sont désormais lus et relevés au minimum de 120 s.
• bind_interface hors Linux est refusé. Sous Windows et macOS, un moteur dont le fichier contient encore bind_interface reste hors réseau (pas d'écoute, pas de connexion sortante, pas d'annonce), avec un avertissement au démarrage bind_interface is Linux-only: … -- this engine will not announce, accept or dial any peer until the key is removed. Retirez la clé et faites tourner le client VPN au niveau du système.
• Force Start sous une file. torrents/setForceStart (« Force Start » de Sonarr/Radarr) était un 404 en 4.3 ; en 4.4.0, c'était un démarrage ordinaire, ou un 409 quand le moteur du torrent a un plafond (avec le modèle, chaque torrent hoard). Depuis la 4.4.1, il force le torrent : démarré, et passé devant la file (File d'attente, limites de partage et de débit).
• Les limites de partage attendent le Minimum seed du tracker. Les limites de ratio et de temps de seed (les vôtres, ou celles qu'envoient Sonarr/Radarr) agissent désormais, mais jamais sur un torrent dont le tracker n'a pas de Minimum seed déclaré dans l'onglet Trackers : il est retenu et journalisé une fois. Déclarez les heures, 0 compris (File d'attente, limites de partage et de débit). active_seeds et active_limit n'agissent qu'avec queueing = true.
• Les boutons de redémarrage sortent avec le code 75. Appliquer et redémarrer (Apply & restart) et les autres commandes de redémarrage font désormais l'arrêt propre complet, puis sortent avec le code 75 (4.3 : code 0, sans l'écriture de reprise). L'unité systemd fournie (Restart=on-failure) et les politiques de redémarrage de Docker relancent Hydranos ; une supervision qui alerte sur un code de sortie non nul le verra (Exploiter Hydranos).

La liste complète est dans le CHANGELOG.