🇬🇧 English · 🇫🇷 Français

S'applique à Hydranos 4.4.

Trouvez votre symptôme, lisez la cause probable, lancez la vérification, appliquez la solution ; l'explication se trouve sur la page liée. Le texte en code est cité exactement tel que Hydranos l'affiche : vous pouvez donc le chercher dans votre journal.

Commencez par réunir trois informations :

• Version : dans l'en-tête de l'interface web, à côté de Démon torrent (Torrent Daemon) ; ou hydranos --version (Docker : docker exec hydranos hydranos --version) affiche hydranos 4.x.y. Sous Windows, utilisez l'en-tête : hydranos.exe est un programme fenêtré dont le --version n'atteint pas de console (d'après le code, non testé).
• Journal : hydranos.log à côté de votre default.toml, heures en UTC. Docker : /config/hydranos.log ou docker logs hydranos. systemd : /etc/hydranos/hydranos.log ou journalctl -u hydranos. Windows : à côté de hydranos.exe (avec --config, à côté de ce fichier), par exemple C:\Hydranos\hydranos.log ; suivez-le dans PowerShell avec Get-Content C:\Hydranos\hydranos.log -Wait. Le fichier tourne de lui-même à 128 Mio (hydranos.log.1 à .4). L'onglet Journaux (Logs) ne garde que les 2000 dernières lignes : pour tout ce qui est plus ancien, lisez le fichier.
• Santé : curl http://127.0.0.1:8199/health répond starting, healthy, degraded (lisez ses problems) ou unhealthy (HTTP 503 : le store ne répond pas, ou aucun moteur n'écoute les pairs) ; en mode de secours, le texte brut ok (Supervision & journaux).

Tous les bouchons (stubs) et bugs connus de la 4.4 sont listés sur Limites connues de la 4.4.

Cause : le port 8199 s'ouvre tout de suite ; tant que les torrents ne sont pas chargés, l'interface affiche l'écran de démarrage et l'API, la connexion, le shim et /mcp répondent 503 (Retry-After: 5) Hydranos is starting (<phase>): <restored> of <total> torrents restored. La ligne de journal hydra API ready y met fin. Solution : patientez ; les clients réessaient. Une connexion refusée signifie que le processus ne tourne pas : lisez le journal. Voir : Pendant le démarrage sur Exploiter Hydranos.

Cause : grep -q healthy correspond aussi à "unhealthy" (et l'image n'a pas curl). Solution : la sonde bash de Docker, qui cherche "status":"(healthy|degraded|starting)" ; starting répond HTTP 200, un long start_period est donc inutile. Docker ne redémarre pas un conteneur marqué unhealthy.

Cause : le fichier de configuration est illisible ou n'est pas du TOML valide. Sous Windows, "C:\Hydranos\data" entre guillemets doubles est une erreur d'échappement TOML. Solution : écrivez "C:/Hydranos/data" ou 'C:\Hydranos\data'. Voir : Windows, Configuration : vue d'ensemble.

Cause : un reverse proxy a transmis un X-Forwarded-For public, ou l'adresse du navigateur n'est pas privée (CGNAT/Tailscale 100.64.0.0/10 compris). Solution : créez le compte une fois depuis la machine ou votre réseau local (http://192.0.2.10:8199), ou lancez hydranos reset-password '<password>' sur l'hôte, comme le dit le message, puis redémarrez. Voir : Sécurité & accès.

Solution : sur l'hôte, hydranos reset-password '<new password>' (8 caractères au moins ; Docker : docker exec hydranos hydranos reset-password '…'), puis redémarrez Hydranos. Sous Windows, quittez d'abord Hydranos ; la commande n'y affiche rien mais écrit le fichier. Ou mettez password_hash = "" sous [auth] pendant l'arrêt : l'écran Bienvenue dans Hydranos (Welcome to Hydranos) revient. La clé API ne change pas. Voir : Sécurité & accès.

Cause : une clé erronée ou ancienne. Une clé vide ou la valeur d'exemple change-me-in-production est remplacée au démarrage ; si default.toml ne peut pas être écrit, le journal indique the API stays closed : une clé vide refuse alors tous les appels, et la valeur d'exemple continue de fonctionner pour quiconque la connaît. Solution : copiez [daemon] api_key depuis default.toml dans vos clients ; dans le second cas, rendez le fichier accessible en écriture et redémarrez. Voir : Sécurité & accès.

Cause : default.toml contient des clés connues pour ne rien faire (restes de la 3.x, listen_interfaces, [bench]…). Solution : faites ce que dit Instead:, supprimez la clé. Voir : Mettre à jour depuis la 3.x, Configuration : vue d'ensemble.

Cause : elle s'ouvre tant que vous n'avez pas cliqué sur Passer (Skip) dans ce navigateur (le choix est enregistré par navigateur) ou qu'un import n'a pas ajouté au moins un torrent. Solution : cliquez une fois sur Passer ; l'assistant reste accessible sous Config › Paramètres avancés (default.toml) (Advanced settings (default.toml)) › Import › Importer… (Import…). Voir : Migrer depuis qBittorrent.

Cause : les dossiers que qBittorrent indique ne sont pas visibles au même chemin pour Hydranos (autre conteneur, autre montage). Solution : dans la correspondance de chemins, mettez dans la colonne de droite le dossier tel que Hydranos le voit, puis Re-check paths jusqu'à ce que chaque ligne affiche ✓. Un Hydranos à l'intérieur de gluetun ne peut pas joindre un qBittorrent du réseau local, sauf si gluetun autorise votre plage d'adresses locale. Voir : l'étape 3 de Migrer depuis qBittorrent.

Cause : chaque torrent importé va dans Hoard, quel que soit le mode de sa catégorie, arrêté par défaut. Seul un torrent complet dans qBittorrent dont le chemin de contenu existe après correspondance saute la vérification des hashs. Une nouvelle exécution ignore les torrents déjà importés. Solution : regardez dans Hoard, et lancez Démarrer (Start) sur ce qui doit seeder ; pour les revérifications, corrigez la correspondance. Voir : Migrer depuis qBittorrent.

Vérification : la liste des échecs affichée à la fin, ou la ligne de journal import: torrent not added et son erreur ; export … http 404 signifie que ce qBittorrent ne propose pas l'endpoint d'export, http 409 (no metadata yet in qBittorrent) un magnet encore sans métadonnées chez lui, (gave up after 4 attempts) un échec qui revenait sans cesse. Solution : corrigez la cause, puis Réessayer les {n} échecs (Retry the {n} failed). Voir : Migrer depuis qBittorrent.

Cause : le 403 Forbidden. répond à tout appel sans session : la connexion a échoué. Fails. (HTTP 200) signifie un nom d'utilisateur, un mot de passe ou une clé erronés, ou un corps JSON au lieu d'un formulaire. Vérification : curl -i --data-urlencode 'username=admin' --data-urlencode 'password=YOUR_PASSWORD' http://127.0.0.1:8199/api/v2/auth/login doit répondre Ok. avec Set-Cookie: SID=…. Solution : compte admin, ou n'importe quel nom d'utilisateur avec la clé API comme mot de passe ; port 8199, sans URL de base. Voir : Shim qBittorrent & automatisation.

Cause : dans gluetun, Hydranos n'a pas de réseau à lui : le nom hydranos ne résout vers rien. Solution : hôte gluetun, port 8199, quand le client partage un réseau Docker défini par l'utilisateur avec gluetun ; sur le réseau bridge par défaut de Docker, l'adresse locale de l'hôte. Voir : VPN & sortie réseau.

Cause : la catégorie est inconnue ou n'a pas de chemin de sauvegarde (une catégorie créée par le client sans savePath n'en a pas et est en hoard), et le client n'a envoyé aucun savepath ni défini de dossier par défaut avec le save_path de setPreferences. Solution : créez-la d'abord dans l'onglet Catégories (Categories) avec un chemin de sauvegarde et le bon Mode. Voir : Catégories & routage.

Cause : Hydranos indique ses propres chemins (ceux du conteneur). Solution : montez le même dossier hôte au même chemin dans les deux conteneurs, ou définissez une correspondance de chemin distant (remote path mapping) dans le client. Voir : Docker, Migrer depuis qBittorrent.

Cause : depuis la 4.4, le shim renvoie les vrais ratio, uploaded et seeding_time (la 4.3 envoyait 0) : l'objectif de seed propre à un client se déclenche désormais, et peut retirer des torrents. Les limites qu'il envoie deviennent des limites de partage Hydranos, retenues tant que le Minimum seed déclaré du tracker n'est pas servi, indéfiniment s'il n'en a pas (journal share limit reached, held: …). Les positions dans la file répondent 409 (utilisez Force Start pour faire passer un torrent devant la file) ; la priorité de fichier 0 est refusée. Solution : réglez Minimum seed (0 compris) dans l'onglet Trackers. Voir : File d'attente, limites de partage et de débit, Shim qBittorrent & automatisation.

Vérification : le message (no save path: …, no engine …, mode must be race or hoard …, <path>: no such file, race disk full: …, N file(s) of this torrent are already another torrent's with other bytes …, torrent already added, torrent file did not parse, this magnet has only a v2 info hash (btmh) …). Solution : voir Quand un ajout est refusé sur Ajouter des torrents & données existantes.

Cause : un autre torrent nomme déjà certains de ses fichiers, avec d'autres octets, et [dedup] path_collision = "isolate" (par défaut) lui a donné son propre dossier, <save path>/<first part of its name> [<first 8 hex digits of its hash>], présenté comme son chemin de sauvegarde. Les fichiers qui se vérifient y sont liés en dur ; le mode seed est abandonné. Solution : rien, ou path_collision = "refuse" sous [dedup] puis redémarrez. Voir : Fichiers qu'un autre torrent détient déjà.

Cause : des fichiers à son chemin qui ont un autre lien physique (typiquement un import Sonarr/Radarr), ou qu'un autre torrent nomme, ne se sont pas vérifiés contre ses pièces ; Hydranos ne les écrasera pas (les revérifications sont protégées de la même façon). Vérification : un WARN path collision: …, ou le type path_collision dans GET /api/health/anomalies. Solution : décidez quel fichier est le bon ; Déplacer vers un dossier… (Set location…) ailleurs, ou retirez le torrent. Voir : Fichiers qu'un autre torrent détient déjà.

Cause : un ajout par-dessus des fichiers existants déclenche une revérification, sauf si l'ajout a demandé le mode seed (Skip the hash check, the data is already on disk de l'onglet d'ajout, les options REST et du shim ; les dossiers surveillés, MCP et les magnets RSS jamais) ; les fichiers revendiqués par un autre chemin sont d'abord prouvés ; ou le dernier arrêt n'a pas été propre. Solution : laissez-la se terminer ; les données correctes ne sont pas retéléchargées. Voir : Ajouter des torrents & données existantes.

Cause : le chemin de sauvegarde n'est pas là où se trouvent les fichiers. Fichier unique : <save path>/<file> ; multi-fichiers : <save path>/<torrent name>/…. Solution : Déplacer vers un dossier… (Set location…) vers le dossier qui contient les données (pour un multi-fichiers, le parent du dossier du torrent). Voir : Jobs, actions groupées & déplacement.

Cause : l'entrée n'apparaît que si la sélection contient au moins une ligne hoard ; une fois affichée, elle revérifie aussi les copies race. Solution : incluez une ligne hoard, ou utilisez la route REST de vérification ou le torrents/recheck du shim. Voir : Jobs, actions groupées & déplacement.

Cause : pas de métadonnées : aucun pair joignable via ses trackers, x.pe ou le DHT, ou le moteur est hors réseau. Après la dernière tentative, le journal indique magnet given up. Solution : Réessayer (Retry), ou ajoutez le fichier .torrent. Voir : Magnets sur Ajouter des torrents & données existantes.

Cause : l'ajout a été refusé ; la raison est dans <name>.invalid.txt à côté. Solution : corrigez la catégorie ou son chemin de sauvegarde, puis redonnez au fichier son nom d'origine. Voir : Dossiers surveillés sur Ajouter des torrents & données existantes.

Vérification : le Statut du dossier sur l'onglet Config. pas encore scanné juste après un démarrage est normal. vus 0 alors que des fichiers sont dans le dossier signifie que Hydranos ne les voit pas : sous Docker, un partage réseau monté sur l'hôte après le démarrage du conteneur laisse le conteneur sur le point de montage vide. Une erreur no answer from this folder for 60 s … signifie que le partage ne répond plus ; les autres dossiers sont toujours analysés. Solution : montez le parent du partage avec la propagation rslave, ou redémarrez le conteneur une fois le partage monté ; pour un partage qui bloque, réparez le montage sur l'hôte. Voir : Dossiers surveillés sur Ajouter des torrents & données existantes.

Cause : avec active_downloads supérieur à 0 (hoard est livré avec 10), un moteur télécharge au plus ce nombre de torrents à la fois ; avec queueing = true, active_limit compte aussi les seeds. Un torrent que vous avez arrêté reste arrêté. Solution : relancez avec Démarrer (Start) ce que vous avez arrêté ; utilisez Forcer le téléchargement (Force download) pour un torrent qui ne doit pas attendre ; augmentez active_downloads (0 = pas de plafond) ou mettez dont_count_slow_torrents = true ; les deux s'appliquent à chaud. Voir : File d'attente, limites de partage et de débit.

Cause : une limite de partage a été atteinte (journal share limit reached: stopped, ou …: removed avec share_limit_action = "remove"), ou, avec queueing = true, active_seeds / active_limit a mis le seed en attente (queuedUP via le shim). Solution : relevez ou supprimez les limites de partage (du moteur, ou Limites de partage… (Share limits…) par torrent), ou les plafonds de la file. Voir : File d'attente, limites de partage et de débit.

Vérification : l'État (State) du flux (blocked by the kill switch, dernière erreur), l'Activity de l'onglet Workflows (RSS: <rule>), l'Aperçu (Preview) de la règle. Causes : règle désactivée ou qui ne surveille pas ce flux ; article déjà pris (une seule fois, refus compris) ; un titre sans numéro d'épisode ne correspond jamais à un filtre d'épisodes ; Ignorer les correspondances suivantes pendant (Ignore later matches for) ; ou aucune catégorie avec un chemin de sauvegarde et pas de Dossier d'enregistrement (Save path) : chaque ajout est refusé avec no save path: …, définitivement. Solution : donnez à la règle une telle catégorie ; ré-ajoutez un article refusé avec Téléchargement (Download). Voir : RSS et téléchargements automatiques.

Cause : la configuration contenait encore des tables [announce_clients] ; les torrents concernés ont été arrêtés une fois. Solution : vérifiez que chaque tracker accepte Hydranos, puis relancez ces torrents avec Démarrer (Start). Voir : Mettre à jour depuis la 3.x.

Vérification : (1) GET /api/port-forward : listening et le listen_port que tient chaque moteur (un port absent ou déjà pris est remplacé : listen_port missing or taken: using a free one) ; (2) les ports sont redirigés, en TCP et en UDP, et publiés sous Docker avec le même numéro des deux côtés ; (3) no automatic port forward; … forward <port> (TCP and UDP) by hand signifie que NAT-PMP/UPnP a échoué (habituel avec le bridge de Docker). Solution : redirigez à la main, mettez auto_port_forward = false, testez depuis l'extérieur. Voir : Vérifier la joignabilité sur Réseau : ports & redirection, le tableau des ports sur Installation & premier démarrage.

Cause : pas en mode Gluetun, Prendre le port d'écoute depuis gluetun (Take the listen port from gluetun) décoché, ou le serveur de contrôle refuse (journal gluetun port forward: cannot read the port ; sur 401/403, set the gluetun API key, with GET /v1/portforward allowed). Tant qu'aucun port n'est lu, ce moteur n'annonce rien. Solution : choisissez Gluetun, cochez la case, renseignez la Clé d'API gluetun (Gluetun API key), Appliquer et redémarrer (Apply & restart). Voir : Avec gluetun sur VPN & sortie réseau.

Cause : le conteneur Hydranos garde l'ancien espace de noms réseau, mort, de gluetun (comportement de Docker, non testé par le mainteneur) ; une reconnexion du tunnel dans un gluetun en marche n'est pas concernée. Solution : redémarrez Hydranos après gluetun : docker restart -t 150 hydranos. Voir : VPN & sortie réseau.

Cause : un moteur sans interface, proxy ni tunnel sort par la route par défaut quand le kill switch est désarmé, ce qui est le réglage par défaut en mode Direct (sa ligne de l'onglet Réseau (Network) indique NOT covered). Un moteur épinglé (Linux) a tous ses sockets sur son interface, annonces et DHT compris. Solution : donnez une sortie au moteur, ou mettez [daemon] kill_switch = true pour qu'il soit bloqué à la place ; vérifiez depuis l'extérieur. Voir : Le kill switch sur VPN & sortie réseau.

Cause : avec le kill switch armé (dans tous les modes sauf Direct, par défaut), la route par défaut n'est pas mesurée : une ligne épinglée ou passant par un proxy ne peut donc que dire qu'« une fuite ne peut pas être exclue » (bug connu en 4.4). Solution : vérifiez depuis l'extérieur (Vérifier, ne pas se fier à l'interface sur VPN & sortie réseau).

Cause : kill switch armé, et le moteur n'a ni interface, ni proxy, ni tunnel, ni allow_direct (WireGuard : Sortie (Way out) sur Non affecté (bloqué par le kill switch) (Not assigned (blocked by the kill switch)) ; Gluetun : épinglé à une autre interface). Journal kill switch: BLOCKED, kept off the network … ; /health indique degraded. Solution : donnez-lui une sortie, cochez Direct assumé (Direct on purpose), ou désarmez le kill switch, puis redémarrez (c'est décidé au démarrage). Voir : VPN & sortie réseau.

Cause : le kill switch est armé et [daemon] egress (auto) n'a rien à emprunter : pas de tunnel (WireGuard), pas de proxy (SOCKS5), ou rien de défini en Direct avec kill_switch = true (kill switch on in direct mode: set [daemon] egress …) ; un engine:<id> bloqué est refusé lui aussi. Solution : donnez à race un tunnel ou un proxy, ou réglez Requêtes externes du démon (External requests of the daemon) sur proxy, direct ou engine:<id>. Voir : Les requêtes propres au démon sur VPN & sortie réseau.

Cause : la carte nomme ce qui manque : Linux, la capacité NET_ADMIN, ou les commandes ip et wg. Solution : Docker : cap_add: [NET_ADMIN], plus HYDRANOS_CAP_NET_ADMIN=1 avec PUID/PGID ; bare metal : accordez la capacité à l'unité ; ailleurs, faites tourner le VPN au niveau du système. Tunnel monté mais pas de port (wireguard: no port yet; the engine starts with its announces held), pas de handshake, fuite de noms : Dépannage sur WireGuard géré.

Cause : les annonces du moteur passent par un proxy SOCKS5 (le sien, ou TYPHON_ANNOUNCE_PROXY) : l'état du tracker indique UDP trackers do not go through a SOCKS5 proxy (no UDP ASSOCIATE): they will not be announced while this proxy is active ; ou enable_udp_trackers = false, ou l'URL n'a pas de port. Voir : Trackers & annonces.

Cause : son interface n'existait pas au démarrage (journal : refusing to listen on the default route) ; + Add an engine refuse une interface inactive avec no interface named <name> is up. Solution : activez l'interface avant Hydranos, redémarrez. Voir : VPN & sortie réseau.

Cause : 409 : le port appartient à un autre moteur ou ne peut pas être attaché (l'ancien est conservé), ou le moteur suit gluetun ou son tunnel WireGuard ; 503 : le moteur est hors réseau. persisted: false : déplacé, mais default.toml n'a pas été écrit. Voir : Changer le port sans redémarrer sur Réseau : ports & redirection.

Cause : le tracker ne connaît pas le torrent (supprimé, remplacé), ou pas encore : juste après un upload, un moteur de rôle race réessaie toutes les 5 s pendant registration_retry_minutes (6 par défaut). Solution : si cela persiste, retirez ou remplacez le torrent. Voir : Trackers & annonces.

Autres classes d'erreur (Passkey invalide (Bad passkey), Quota atteint (Rate-limited), Tracker injoignable (Tracker unreachable)) : voir le tableau de dépannage sur Trackers & annonces.

Cause : une copie faite par Duplicate to engine › (elle part des trackers du .torrent stocké), ou un déplacement fait sous la 4.4.0 : voir Après un déplacement, les modifications de trackers… ci-dessous.

Cause : shared (un autre torrent, ou la copie de ce même torrent dans un autre moteur, lit les mêmes fichiers), destination_taken (des fichiers déjà présents à la destination seraient écrasés), hardlinks (une copie casserait un lien physique ; l'interface demande d'abord), space, unsafe_path, ou un déplacement déjà en file. Voir : Vérifications avant la mise en file d'un déplacement sur Jobs, actions groupées & déplacement.

Cause : un job move_data en cours n'est jamais interrompu (409 a running move cannot be interrupted safely; it will finish) ; un job en file est abandonné, un job graduate en cours s'arrête après le fichier courant et est annulé (retour arrière). Solution : laissez-le se terminer. Voir : Jobs, actions groupées & déplacement.

Cause : sous la 4.4.0, un job move_data (Déplacer vers un dossier…, un déplacement de catégorie au sein d'un même mode, l'action de workflow move files to a folder) ré-ajoutait le torrent en mode seed depuis le .torrent stocké : modifications de trackers, compteurs, plafonds et ordre de téléchargement étaient perdus, et un torrent incomplet était marqué complet. Depuis la 4.4.1, tout déplacement les conserve, mais ce qu'un déplacement en 4.4.0 a perdu reste perdu. Une copie faite par Duplicate to engine › part toujours des trackers du .torrent et de compteurs à 0. Solution : refaites les modifications ; lancez Vérifier à nouveau (Recheck) sur un torrent déplacé inachevé sous la 4.4.0. Voir : Jobs, actions groupées & déplacement.

Cause : une graduation échouée ou annulée est défaite (retour arrière) ; seul un retour arrière qui échoue laisse le torrent dans aucun moteur. (Move to engine › ne le fait jamais : la cible adopte d'abord.) Solution : ajoutez de nouveau le .torrent à ce dossier, depuis Télécharger les .torrent (.zip) (Download .torrent files (.zip)) ou une sauvegarde. Voir : Jobs, actions groupées & déplacement.

Cause : le Minimum seed du tracker était faux : 0 signifie « supprimer quand c'est nécessaire ». Un tracker sans rien de déclaré est protégé (déplacé ou laissé en place, jamais supprimé). Solution : ne déclarez que le Minimum seed que vous voulez vraiment, pour chaque tracker sur lequel vous faites de la race. Voir : Drain race & graduation.

Cause : l'éditeur enregistre un nouveau workflow désactivé (l'enregistrement d'une modification conserve son état). Solution : cochez Enabled dans la liste après le premier enregistrement ; Lancer maintenant (Run now) exécute une fois un workflow à minuterie, activé ou non. Voir : Workflows.

Cause : Modifier les tags › (Edit tags ›), Forcer le téléchargement / Ne plus forcer (Stop forcing) et Limites de partage… ne sont pas relayés aux nœuds ({n} not on this node) ; les autres actions sont relayées et un refus revient sous la forme <node>: <the node's error>. no declared node holds <label> signifie que le nœud de la ligne n'est plus déclaré. Solution : ouvrez le nœud avec Open depuis l'onglet Nodes et agissez dans sa propre interface. Voir : Nœuds & plusieurs machines.

Cause : il ne remplace qu'un conteneur qu'il a lui-même créé (label io.hydranos.enrolled=true). Solution : --container <another-name>, ou supprimez ce conteneur vous-même. Un nom déjà déclaré est refusé (409) sans consommer le jeton : relancez avec --name. Voir : Nœuds & plusieurs machines.

Cause : avec PUID/PGID, l'entrypoint fait un chown de /config mais jamais de /data, et un dossier que Docker crée pour un montage bind manquant appartient à root. Vérification : ls -ln sur les dossiers hôtes derrière vos chemins de sauvegarde. Solution : créez-les avant le premier démarrage et donnez-les à cet uid:gid ; sur Unraid, 99:100 correspond aux partages utilisateur. Si le journal indique hydranos: already running as uid <N>, ignoring PUID/PGID, retirez le --user de Docker. Voir : Utilisateur et permissions sur Docker.

Cause : /config n'est pas monté : tout vivait donc dans la couche du conteneur. (Aucun « mot de passe admin temporaire » n'est jamais journalisé.) Solution : montez un dossier hôte en /config. Voir : Docker.

Cause : toute valeur de HYDRANOS_LOG_STDOUT, 0 compris, désactive le fichier et ne laisse que la console. Solution : retirez la variable. Voir : Docker.

Cause : /config sur /mnt/user/… (FUSE, traité comme un système de fichiers réseau). Solution : mappez /config vers un chemin de pool comme /mnt/cache/appdata/hydranos. Voir : Unraid sur Docker.

Cause : la 4.3 lancée sans --config utilisait \config\default.toml sur le lecteur courant (C:\config\) ; s'il n'y a pas de default.toml à côté de hydranos.exe, la 4.4 continue de l'utiliser. Solution : quittez Hydranos, déplacez le contenu de C:\config\ à côté de hydranos.exe et corrigez data_dir, ou lancez avec --config. Voir : Où va la config sur Windows.

Cause : l'arrêt propre a pris plus de 60 s (la sauvegarde d'une grosse bibliothèque), ou le Hydranos en marche est antérieur à la 4.4 et n'a pas entendu la demande. Solution : attendez que hydranos.exe disparaisse du Gestionnaire des tâches (ou zone de notification › Quit Hydranos), puis relancez la mise à jour. Voir : Mise à jour sur Windows.

Cause : à l'arrêt, à la déconnexion ou quand sa fenêtre de console est fermée, Windows ne laisse à Hydranos que quelques secondes pour sauvegarder, et un programme fenêtré peut ne pas recevoir du tout l'événement d'arrêt (non testé sous Windows). Solution : zone de notification › Quit Hydranos d'abord, et attendez que hydranos.exe disparaisse du Gestionnaire des tâches. Voir : Arrêter proprement sur Windows.

Cause : bind_interface est réservé à Linux : refusé (400) par l'onglet Réseau et + Add an engine ; un moteur dont le fichier le définit encore démarre hors réseau. Interface du démon (Daemon interface) est acceptée, puis toute requête du démon qui n'emprunte pas la route d'un moteur est refusée, [proxy] compris (bug connu en 4.4). Solution : retirez la clé et redémarrez ; laissez Interface du démon vide ; faites tourner le VPN au niveau du système. Voir : VPN sous Windows sur Windows.

Cause : mode de secours : hydra.db ne s'est pas ouvert ou a échoué à sa vérification de schéma (journal : the store could not be opened: <why> -- starting in rescue mode) ; seules quelques routes sont servies, sur vos api_host et api_port. Vérification : curl http://127.0.0.1:8199/api/store/repair (sans clé) affiche needed, on_network et in_wal. Solution : copiez d'abord le dossier de configuration ; déplacez le dossier de données sur un disque local. POST /api/store/repair ne s'applique qu'à un store en WAL sur un système de fichiers réseau. Voir : Mode de secours sur Exploiter Hydranos.

Cause : les redémarrages par l'interface s'arrêtent proprement, puis se terminent avec le code 75 pour que le superviseur relance : Docker sans politique de redémarrage (l'Autostart d'Unraid n'en définit aucune) ou un lancement à la main sous Linux le laissent arrêté. L'unité systemd livrée (Restart=on-failure) le relance ; Windows démarre lui-même son successeur. Solution : restart: unless-stopped (--restart=unless-stopped), ou démarrez-le à la main. Voir : Redémarrer depuis l'interface sur Exploiter Hydranos.

Cause : le superviseur a tué le processus pendant l'écriture de reprise, ou l'écriture a atteint HYDRANOS_STOP_TIMEOUT ; c'est alors la dernière sauvegarde périodique (300 s) qui est utilisée. Vérification : un arrêt propre se termine par shutdown flush complete (took_s) ; shutdown flush hit HYDRANOS_STOP_TIMEOUT; leaving with what is saved signifie que le budget (120 s par défaut ; 10s vaut 10 s) est épuisé ; aucune ligne signifie qu'il a été tué. Solution : augmentez HYDRANOS_STOP_TIMEOUT au-dessus de took_s, et la limite du superviseur (stop_grace_period, docker stop -t, TimeoutStopSec) 10 s au-dessus. Voir : Exploiter Hydranos.

Cause : bench.db dans le dossier de données n'a pas de rétention (environ 17 000 lignes d'échantillons par jour, plus autant par moteur supplémentaire). Le journal tourne de lui-même et occupe au plus environ 640 Mio (5 × 128 Mio). Solution : surveillez la taille de bench.db ; pour garder un journal plus petit, baissez le niveau avec RUST_LOG. Voir : Supervision & journaux.

Cause : lisez ses problems : un moteur sur le réseau sans son écoute de pairs (port non attaché, ou son tunnel est tombé), un moteur bloqué par le kill switch, ou un moteur retenu par start_paused. Les autres moteurs continuent de seeder. Voir : Supervision & journaux.

Cause : update_check_disabled = true ; la requête à GitHub a échoué ou a pris plus de 5 s (un échec n'est pas conservé, il est donc retenté à la requête suivante ; un succès est conservé 6 heures) ; ou la version la plus récente n'est pas parmi les 100 premiers tags renvoyés. Solution : surveillez les releases sur github.com/Kheopsian/Hydranos. Voir : Exploiter Hydranos.

Références mesurées : Topologies de déploiement.

Cause : la mémoire augmente avec les torrents et les pairs connectés (pas de clé max_connections = pas de limite), et l'allocateur garde la mémoire libérée. Vérification : la ligne jemalloc allocated=… resident=… journalisée toutes les 300 s sous Linux. Solution : réglez max_connections par moteur ; sous Linux, kill -USR2 <pid> fait rendre la mémoire inutilisée par l'allocateur. Voir : Supervision & journaux, Config : moteurs & drain race.

Cause : revérifications après un arrêt non propre (4 à la fois par défaut, TYPHON_RECHECK_TORRENTS), chargement du catalogue, montée en charge des annonces. Solution : arrêts propres, laissez se stabiliser. Voir : Config : environnement, CLI & signaux.

Vérification : des avertissements store held long ; HYDRANOS_WORKER_THREADS (par défaut min(cores, 32)). La passe d'anomalies tourne d'elle-même toutes les 5 minutes ; interroger /api/health/anomalies ne fait que lire son dernier résultat. Voir : Supervision & journaux.

Ouvrez une issue sur github.com/Kheopsian/Hydranos/issues (le lien Signaler un problème (Report issue) de l'onglet Journaux en ouvre une). Indiquez :

1. la version et la façon dont vous le faites tourner (étiquette d'image, systemd, Windows) ;
2. ce que vous avez fait, ce que vous attendiez et ce que vous avez obtenu ;
3. les lignes de hydranos.log autour du problème (UTC) ;
4. default.toml sans les secrets (api_key, password_hash, [announce_passkeys], clés des nœuds, URL de trackers contenant une passkey) ;
5. pour les performances : les lignes jemalloc … et store held long, le nombre de torrents par moteur.

Les URL des lignes announce failed (http(s) seulement, pas udp://) et qbit add: url refused sont remplacées par <url> ; les autres lignes ne le sont pas. Vérifiez avant de coller.