Dépannage Train at Home : arrêt la nuit, file bloquée, « no routable peers »

La plupart des symptômes de Train at Home qui ressemblent à une panne sont soit un comportement attendu que l'interface officielle n'explique jamais, soit une cause identifiable directement dans le journal CLI. Ce guide avance symptôme par symptôme, en s'appuyant sur ce que le journal et la documentation officielle disent réellement — pas sur des suppositions sur le fonctionnement interne du back-end de Macrocosmos.

« Ça s'est arrêté pendant la nuit »

C'est un comportement attendu, pas un bug. La FAQ officielle est explicite : « L'entraînement s'arrête automatiquement. Rien ne continue de tourner quand l'application est fermée ou que votre ordinateur se met en veille. » Train at Home ne maintient aucune revendication d'activité qui lui soit propre — si votre Mac s'est mis en veille, l'entraînement s'est arrêté à cet instant précis, et a besoin d'une méthode anti-veille pour survivre à une session sans surveillance. Voir le guide sur la veille pour la configuration exacte caffeinate/pmset, et le guide de configuration optimale pour la checklist complète.

La position grimpe au lieu de descendre

Si votre position affiche ▲ (en hausse) au lieu de ▼ (en baisse), quelque chose vous a ré-inscrit. Redémarrer l'application officielle — même pour « réparer » un chiffre qui semblait bloqué — envoie une nouvelle requête d'inscription, à laquelle l'orchestrateur répond par un tout nouvel identifiant de file, à la position actuelle de la fin de la file. La solution consiste simplement à arrêter de redémarrer : laissez tourner, et la position redescend d'elle-même. Voir le guide sur la position dans la file pour savoir précisément quels champs du journal surveiller.

Bloqué sur « confirmed » pendant longtemps

confirmed est un statut d'inscription, pas un blocage. D'après le propre analyseur de cette application (construit en observant de vraies réponses d'inscription), le cycle de vie est : queued (en file) → processing/confirming → confirmed → succeeded. confirmed signifie précisément que l'application attend toujours qu'un emplacement de couche se libère — cela peut durer des heures avant que succeeded arrive et que l'entraînement réel commence. Ce n'est pas la preuve que quelque chose est cassé ; il n'existe simplement aucune garantie publiée sur la durée possible de cette attente.

Une erreur de l'orchestrateur qui vous a fait perdre votre place

Les appels de statut d'inscription échouent parfois côté serveur. Dans un cas observé, /miner/register/status a répondu 500 trois fois de suite ; l'application s'est alors ré-inscrite avec un tout nouvel identifiant de file, repartant de la fin. Il s'agit d'une erreur côté orchestrateur, pas de quelque chose que vous avez provoqué, et aucun réglage local ne permet de l'éviter — si vous voyez une salve de réponses 500/503 dans le journal au moment où votre position se réinitialise, c'est l'explication la plus probable. Cela reste assez rare ; si ça se reproduit constamment, mieux vaut le signaler à Macrocosmos plutôt que de soupçonner votre propre installation.

Des avertissements persistants « No routable peers »

Une ligne comme No routable peers for layer-<N> (activation <uuid>): 0 node(s) matched signifie que l'application n'a pas trouvé de partenaire pair-à-pair pour un transfert de données précis, à ce moment-là.

Le guide réseau et ports détaille ce que vous pouvez vérifier localement (lsof -nP -i, l'historique de « Registered with P2P node ID ») et ce qu'éviter un VPN par précaution générale permet d'écarter.

Retombé en file après avoir travaillé

Passer directement de l'entraînement actif à la file, sans redémarrage de votre part, est un motif réel que les outils de suivi de flotte de ce projet surveillent (en interne : une transition working → queued entre deux rapports). Ce qui provoque un cas précis n'est pas documenté publiquement par Macrocosmos, donc ce guide ne spéculera pas sur la raison pour laquelle l'orchestrateur a réattribué cet emplacement. Ce qui est établi : c'est un état normal dont le mineur peut se remettre tout seul, de la même façon qu'après un redémarrage — rien n'indique qu'il s'agisse d'un état punitif ou permanent, juste d'un emplacement qui a changé de main.

Le travail affiche toujours « idle »

C'est attendu tant que vous n'avez pas atteint le front de la file d'admission et reçu une couche à traiter — idle signifie simplement que vous avez dépassé l'inscription mais n'avez pas encore reçu de travail. Cela se résout tout seul une fois l'affectation faite ; ce n'est pas quelque chose à corriger.

Un résultat de speed test anormalement bas

Le résultat du speed test intégré au mineur dépend surtout du serveur tiré, pas de votre ligne réelle. Une comparaison documentée, même ligne et même après-midi, a montré 995 Mbps en descendant avec networkQuality de macOS contre à peine 13,8 Mbps avec le test intégré du mineur plus tard ce même après-midi — un pur artefact de sélection de serveur. Avant de conclure que votre connexion est en cause, comparez avec networkQuality comme décrit dans le guide sur le speed test. Un tel résultat peut aussi coïncider avec les erreurs d'orchestrateur décrites plus haut, une tentative d'inscription qui traîne et une réponse de la série 500 pouvant apparaître proches l'une de l'autre dans le journal.

Quand simplement attendre

Plusieurs symptômes ci-dessus — une longue attente sur confirmed, un statut de travail idle, une seule ligne « no routable peers », une erreur d'inscription isolée — font partie du déroulement normal, pas d'une panne. La seule action réellement contre-productive dans tout ce guide est de redémarrer l'application officielle « au cas où » : c'est la seule chose de cette liste qui aggrave systématiquement votre position.

Checklist

1. Vérifiez que l'application officielle tourne bien et que son journal se met à jour (pas ⛏ off).
2. En cas d'arrêt pendant la nuit, mettez en place une méthode anti-veille — voir le guide sur la veille.
3. Si votre position grimpe, arrêtez de redémarrer l'application et laissez-la se rétablir seule.
4. Considérez une longue phase confirmed et un statut idle comme normaux, pas comme une panne.
5. Notez toute salve de 500/503 autour d'une réinitialisation de position — c'est un événement côté orchestrateur, pas à corriger de votre côté.
6. Pour « no routable peers », lisez le guide réseau avant de penser à une mauvaise configuration.
7. Pour un speed test anormalement bas, comparez avec networkQuality via le guide sur le speed test.
8. Installez subnera (ou subnera hub pour plusieurs Mac) pour voir ces signaux sans relire le journal brut à chaque fois.

Si rien de tout cela ne correspond à ce que vous observez, le guide de configuration optimale reste le meilleur point de départ pour une revue complète de votre installation.