1. Distinguer quatre états que l’écran mélange
Une connexion ouverte prouve seulement que vous pouvez encore dialoguer avec la machine. Un terminal visible peut héberger un shell dont le calcul est déjà terminé. À l’inverse, perdre la connexion ne permet pas de conclure que le processus s’est arrêté. Commencez donc par donner un nom à l’exécution et à l’endroit où retrouver ses traces.
Suivez séparément l’existence du processus, sa progression métier et l’acceptation du résultat. Le nombre de lignes dans un journal n’est pas un compteur de données réussies : un programme peut répéter le même avertissement. Une sortie partielle peut être lisible tout en étant incomplète.
Cette méthode suppose que vous avez reçu et vérifié les moyens d’accès nécessaires. Elle ne promet ni un protocole d’accès particulier ni une conservation automatique des fichiers. Les outils et destinations disponibles doivent être contrôlés dans l’environnement effectivement fourni.
Faites défiler le tableau pour lire toutes les colonnes.| Observation | Ce qu’elle indique | Ce qu’elle ne démontre pas |
|---|---|---|
| Connexion active | Le canal répond. | Le calcul avance. |
| Processus présent | Une exécution existe encore. | Elle traite les bons éléments. |
| Compteur validé en hausse | Des unités prévues sont terminées. | Tout le corpus est terminé. |
| Code de retour égal à zéro | Le programme annonce une terminaison normale. | Le résultat respecte votre contrat. |
| Sorties contrôlées et récupérées | Les critères choisis ont été vérifiés. | Une qualité au-delà de ces critères. |
2. Préparer une exécution identifiable avant de la détacher
Contrôlez les données, la configuration effective et un premier passage court de l’application. Le diagnostic GPU répond à une autre question : le backend sait-il exécuter un calcul ? Il ne valide pas le chargement complet du corpus ni la logique de votre programme. Réalisez ces vérifications avant de lancer une durée importante.
Choisissez un identifiant d’exécution et un dossier neuf. Conservez la commande sans secret, la version du code, l’identité des entrées et le résultat attendu. Prévoyez où écrire les journaux et où récupérer les fichiers. Deux lancements ne doivent pas écrire simultanément dans le même dossier.
Pour un travail divisé en partitions indépendantes, décidez quand une partition devient terminée : calcul achevé, fichier fermé, contenu contrôlé et état enregistré. Un fichier en cours d’écriture ne doit pas avoir la même signification qu’un résultat accepté. Vérifiez également l’espace réellement utilisable avant le départ.
3. Garder un terminal retrouvable quand le contexte le permet
Si l’environnement propose un shell Unix et tmux, ce multiplexeur permet de détacher un terminal et de le retrouver après une reconnexion. Il protège ce parcours contre la perte du client de connexion ; ce n’est pas un mécanisme de reprise après redémarrage de la machine ou destruction du processus.
Les commandes ci-dessous sont pédagogiques et non exécutées. Elles supposent Bash, tmux et votre propre programme traitement.py, avec les options montrées ; ce fichier n’est pas une ressource fournie. Vérifiez d’abord sa commande courte et utilisez un nom de session distinct pour ne pas confondre deux calculs.
Créez la session, puis lancez le second bloc à l’intérieur. La création du dossier échoue s’il existe déjà, ce qui évite de réutiliser silencieusement ses journaux. Le code de retour est conservé si le shell atteint l’étape d’écriture ; un arrêt brutal peut empêcher la création de ce fichier. L’absence de code n’est donc pas un succès implicite.
Avec les raccourcis par défaut, détachez avec Ctrl-b puis d. Après reconnexion, listez les sessions puis rattachez la bonne. Le shell peut rester visible alors que le programme a fini : consultez le journal et le code enregistré. Ne démarrez pas immédiatement une deuxième copie parce que votre ancien terminal a disparu.
tmux new -s campagne-amkdir -p runs
mkdir runs/campagne-a && (
code_retour=0
python -u traitement.py --config config.toml --output runs/campagne-a \
> runs/campagne-a/execution.log 2>&1 || code_retour=$?
printf '%s\n' "$code_retour" > runs/campagne-a/exit-code.txt
exit "$code_retour"
)tmux ls
tmux attach -t campagne-a4. Compter du travail accepté, pas seulement de l’activité
L’option Python -u retire la mise en tampon de ses sorties standard et d’erreur. Elle aide à voir les messages émis, mais ne crée pas d’événements de progression dans l’application. Une bibliothèque ou une étape silencieuse peut encore demander une observation propre.
Définissez des phases compréhensibles : lecture, préparation, calcul, écriture, vérification. Ajoutez un compteur dont l’unité est stable, ainsi qu’un total lorsqu’il est connu. Si vous comptez des partitions acceptées, ne passez pas à un compteur de lignes lues au milieu du journal sans changer son nom.
L’exemple pédagogique suivant porte sur huit partitions de cinq cents éléments, soit quatre mille éléments. À l’instant illustré, seules cinq partitions sont acceptées. La sixième est partielle et ne doit pas gonfler le total. Les nombres montrent une règle de comptage ; ils ne décrivent aucune exécution Kernodeck.
Faites défiler le tableau pour lire toutes les colonnes.| Partitions | État | Éléments comptés comme acceptés | Décision |
|---|---|---|---|
| 1 à 5 | Vérifiées | 2 500 | Conserver leurs identités et résultats. |
| 6 | Écriture partielle | 0 | Ne pas annoncer cette partition terminée. |
| 7 et 8 | À traiter | 0 | Rester dans la liste de travail. |
| Ensemble | Incomplet | 2 500 sur 4 000 | Ne pas accepter le dossier final. |
5. Examiner un silence ou une interruption sans créer de doublon
Lorsqu’aucun compteur ne bouge, identifiez la dernière phase connue et sa dernière unité terminée. Vérifiez si le processus existe, si un message d’erreur est apparu et si la destination reste utilisable. Un démarrage lent du modèle et une boucle bloquée peuvent produire le même écran immobile ; le contexte décide du contrôle suivant.
Préparez l’arrêt volontaire dans votre application : demande d’arrêt, fin d’une unité sûre, enregistrement d’état, puis sortie. Les signaux et interruptions dépendent du système. Python ne peut pas intercepter SIGKILL, et un gestionnaire Python peut attendre la fin d’un long appel natif avant de s’exécuter. Une sauvegarde à l’arrêt ne remplace donc pas des sauvegardes périodiques.
Après une perte de connexion, retrouvez d’abord la session et l’exécution existantes. Après un arrêt confirmé, déterminez ce qui est complet et ce qui est partiel. Pour un entraînement, la reprise demande les états détaillés du modèle et de l’optimisation ; le guide dédié vérifie ce cas dans un nouveau processus.
6. Reprendre seulement ce que le contrat permet
Dans notre exemple, la reprise par partition suppose que chaque partition est indépendante et que l’entrée, le code et la configuration restent identiques. Elle peut conserver les cinq résultats validés et recalculer la sixième entièrement avant de poursuivre les deux suivantes. Si ces hypothèses ne tiennent pas, ce raccourci n’est pas justifié.
N’ajoutez pas simplement les nouvelles lignes au fichier partiel. Vous risqueriez de produire des doublons ou de mélanger deux configurations. Utilisez les identifiants attendus pour distinguer complet, incomplet et absent. Conservez l’ancien état comme élément d’explication, avec une destination séparée pour la nouvelle tentative.
Vérifiez votre stratégie sur une interruption contrôlée avant d’en dépendre pour un gros traitement. Le critère est l’équivalence des sorties utiles selon votre contrat, pas l’identité des messages de progression. Les entraînements, calculs avec effets extérieurs et traitements distribués demandent d’autres garanties que cet exemple de partitions indépendantes.
7. Accepter et récupérer le résultat avant de clore le travail
Commencez par le code de retour, puis rapprochez les sorties du manifeste d’entrée. Pour notre exemple, attendez les huit partitions et les quatre mille identifiants prévus, sans manque ni doublon. Contrôlez le format, les dimensions et les valeurs pertinentes ; lire un fichier ne démontre pas qu’il contient le bon résultat.
Récupérez les sorties acceptées, la configuration autorisée, les versions et le rapport de contrôle. Comparez les tailles et, si nécessaire, les empreintes entre origine et copie. Une empreinte identique aide à vérifier le transfert des octets ; elle ne prouve ni la qualité du modèle ni la provenance légitime du fichier.
Ouvrez enfin un résultat depuis sa destination de conservation, avec l’outil qui l’utilisera. Prévoyez cette étape avant la fin de votre accès au calcul. Le travail est terminé lorsque le résultat contrôlé est récupérable et interprétable, pas lorsque le dernier pourcentage a atteint cent.