1. Distinguir cuatro estados que la pantalla mezcla
Una conexión abierta solo demuestra que todavía puedes dialogar con la máquina. Un terminal visible puede alojar un shell cuyo cálculo ya ha terminado. A la inversa, perder la conexión no permite concluir que el proceso se haya detenido. Así que empieza por dar un nombre a la ejecución y al lugar donde encontrar sus rastros.
Sigue por separado la existencia del proceso, su progreso de negocio y la aceptación del resultado. El número de líneas en un registro no es un contador de datos exitosos: un programa puede repetir la misma advertencia. Una salida parcial puede ser legible y a la vez estar incompleta.
Este método supone que has recibido y verificado los medios de acceso necesarios. No promete ni un protocolo de acceso concreto ni una conservación automática de los archivos. Las herramientas y destinos disponibles deben comprobarse en el entorno efectivamente proporcionado.
Desplaza la tabla para leer todas las columnas.| Observación | Lo que indica | Lo que no demuestra |
|---|---|---|
| Conexión activa | El canal responde. | El cálculo avanza. |
| Proceso presente | Todavía existe una ejecución. | Procesa los elementos correctos. |
| Contador validado al alza | Se han terminado unidades previstas. | Todo el corpus está terminado. |
| Código de retorno igual a cero | El programa anuncia una terminación normal. | El resultado respeta tu contrato. |
| Salidas controladas y recuperadas | Se han verificado los criterios elegidos. | Una calidad más allá de esos criterios. |
2. Preparar una ejecución identificable antes de desacoplarla
Controla los datos, la configuración efectiva y una primera pasada corta de la aplicación. El diagnóstico de GPU responde a otra pregunta: ¿sabe el backend ejecutar un cálculo? No valida la carga completa del corpus ni la lógica de tu programa. Realiza estas comprobaciones antes de lanzar una duración importante.
Elige un identificador de ejecución y una carpeta nueva. Conserva el comando sin secretos, la versión del código, la identidad de las entradas y el resultado esperado. Prevé dónde escribir los registros y dónde recuperar los archivos. Dos lanzamientos no deben escribir simultáneamente en la misma carpeta.
Para un trabajo dividido en particiones independientes, decide cuándo una partición pasa a estar terminada: cálculo finalizado, archivo cerrado, contenido controlado y estado guardado. Un archivo en proceso de escritura no debe tener el mismo significado que un resultado aceptado. Verifica también el espacio realmente utilizable antes de empezar.
3. Mantener un terminal localizable cuando el contexto lo permita
Si el entorno ofrece un shell Unix y tmux, este multiplexor permite separar un terminal y recuperarlo tras una reconexión. Protege este recorrido contra la pérdida del cliente de conexión; no es un mecanismo de recuperación tras el reinicio de la máquina o la destrucción del proceso.
Los comandos siguientes son didácticos y no se ejecutan. Suponen Bash, tmux y tu propio programa tratamiento.py, con las opciones mostradas; este archivo no es un recurso proporcionado. Verifica primero su comando corto y usa un nombre de sesión distinto para no confundir dos cálculos.
Crea la sesión y luego lanza el segundo bloque dentro de ella. La creación de la carpeta falla si ya existe, lo que evita reutilizar silenciosamente sus registros. El código de retorno se conserva si el shell llega al paso de escritura; una interrupción brusca puede impedir la creación de ese archivo. Por lo tanto, la ausencia de código no es un éxito implícito.
Con los atajos predeterminados, sepárala con Ctrl-b y luego d. Tras reconectarte, lista las sesiones y vuelve a enganchar la correcta. El shell puede seguir visible aunque el programa haya terminado: consulta el registro y el código guardado. No inicies de inmediato una segunda copia solo porque tu terminal anterior haya desaparecido.
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. Contar el trabajo aceptado, no solo la actividad
La opción -u de Python elimina el búfer de sus salidas estándar y de error. Ayuda a ver los mensajes emitidos, pero no crea eventos de progreso en la aplicación. Una biblioteca o un paso silencioso aún pueden requerir una observación propia.
Define fases comprensibles: lectura, preparación, cálculo, escritura, verificación. Añade un contador cuya unidad sea estable, así como un total cuando se conozca. Si cuentas particiones aceptadas, no pases a un contador de líneas leídas a mitad del registro sin cambiar su nombre.
El siguiente ejemplo didáctico trata de ocho particiones de quinientos elementos, es decir, cuatro mil elementos. En el instante ilustrado, solo se aceptan cinco particiones. La sexta es parcial y no debe inflar el total. Los números muestran una regla de conteo; no describen ninguna ejecución de Kernodeck.
Desplaza la tabla para leer todas las columnas.| Particiones | Estado | Elementos contados como aceptados | Decisión |
|---|---|---|---|
| 1 a 5 | Verificadas | 2 500 | Conservar sus identidades y resultados. |
| 6 | Escritura parcial | 0 | No anunciar esta partición como terminada. |
| 7 y 8 | Por procesar | 0 | Permanecer en la lista de trabajo. |
| Conjunto | Incompleto | 2 500 de 4 000 | No aceptar la carpeta final. |
5. Examinar un silencio o una interrupción sin crear duplicados
Cuando ningún contador se mueve, identifica la última fase conocida y su última unidad terminada. Comprueba si el proceso existe, si apareció un mensaje de error y si el destino sigue siendo utilizable. Un inicio lento del modelo y un bucle bloqueado pueden producir la misma pantalla inmóvil; el contexto decide la siguiente comprobación.
Prepara la parada voluntaria en tu aplicación: solicitud de parada, fin de una unidad segura, guardado de estado y luego salida. Las señales e interrupciones dependen del sistema. Python no puede interceptar SIGKILL, y un manejador de Python puede esperar a que termine una larga llamada nativa antes de ejecutarse. Por lo tanto, un guardado al detenerse no sustituye a los guardados periódicos.
Tras una pérdida de conexión, recupera primero la sesión y la ejecución existentes. Tras una parada confirmada, determina qué está completo y qué está parcial. Para un entrenamiento, la reanudación requiere los estados detallados del modelo y de la optimización; la guía dedicada verifica este caso en un nuevo proceso.
6. Reanudar solo lo que el contrato permite
En nuestro ejemplo, la reanudación por partición supone que cada partición es independiente y que la entrada, el código y la configuración permanecen idénticos. Puede conservar los cinco resultados validados y recalcular el sexto por completo antes de continuar con los dos siguientes. Si estos supuestos no se cumplen, este atajo no está justificado.
No te limites a añadir las nuevas líneas al archivo parcial. Correrías el riesgo de producir duplicados o de mezclar dos configuraciones. Usa los identificadores esperados para distinguir completo, incompleto y ausente. Conserva el estado anterior como elemento de explicación, con un destino separado para el nuevo intento.
Verifica tu estrategia con una interrupción controlada antes de depender de ella para un procesamiento grande. El criterio es la equivalencia de las salidas útiles según tu contrato, no la identidad de los mensajes de progreso. Los entrenamientos, los cálculos con efectos externos y los procesamientos distribuidos exigen otras garantías que este ejemplo de particiones independientes.
7. Aceptar y recuperar el resultado antes de cerrar el trabajo
Empieza por el código de retorno y luego contrasta las salidas con el manifiesto de entrada. Para nuestro ejemplo, espera las ocho particiones y los cuatro mil identificadores previstos, sin faltantes ni duplicados. Controla el formato, las dimensiones y los valores relevantes; leer un archivo no demuestra que contenga el resultado correcto.
Recupera las salidas aceptadas, la configuración autorizada, las versiones y el informe de control. Compara los tamaños y, si es necesario, las huellas entre el origen y la copia. Una huella idéntica ayuda a verificar la transferencia de los bytes; no prueba ni la calidad del modelo ni la procedencia legítima del archivo.
Por último, abre un resultado desde su destino de conservación, con la herramienta que lo utilizará. Prevé este paso antes de que termine tu acceso al cómputo. El trabajo está terminado cuando el resultado controlado se puede recuperar e interpretar, no cuando el último porcentaje llegó a cien.