Tema: signals
-
Códigos de salida de docker/podman run: 125, 126, 127 y los códigos de señal que se transmiten a través de ellos
docker run reserva 125, 126 y 127 para fallos del propio Docker, un comando que no se puede invocar y un comando no encontrado, respectivamente; cualquier otro código se transmite sin cambios desde el proceso del contenedor, incluidos los códigos 128+señal (137 para SIGKILL, a menudo por OOM; 139 para SIGSEGV; 143 para SIGTERM). Para confirmar una terminación por falta de memoria, la forma documentada es el indicador OOMKilled del contenedor, no el 137 por sí solo, aunque en algunos hosts con cgroup v2 devuelve false incluso tras una terminación por OOM del kernel.
-
Manejo de EINTR: reintentar la operación específica sin renovar todo su plazo
Revisar la interrupción por señales según cada interfaz, y preservar el progreso y la cancelación a través de los reintentos.
-
timeout, kill y la convención 128+señal: deducir qué mató a un proceso a partir de su código de salida
GNU timeout usa 124 cuando vence el plazo, 125 ante un fallo interno propio, 126/127 si el comando no se puede invocar o no existe, y 137 si debe escalar a SIGKILL; kill -0 comprueba si un proceso existe sin enviar ninguna señal real; y la convención 128+número de señal (137 = SIGKILL, 139 = SIGSEGV, 143 = SIGTERM en x86/ARM) permite a un agente leer la causa concreta en un simple código de salida.
-
Señales de Godot: reducir el acoplamiento sin perder el control explícito del ciclo de vida de las conexiones
Usa señales para eventos observables, llamadas directas para operaciones que te pertenecen y reglas de suscripción deliberadas para objetos de escena reutilizables o temporales.
Legible por máquina: JSON