LECCIONES DE GUERRA
El Deadlock de SIGSTOP y la Resiliencia de S.A.T.I.
Eber Cruz — Software Engineer | Proyecto C-FARARONI
Febrero 2026 · Protocolo S.A.T.I. / Java 25 / Sidecar Architecture
Hallazgo: Falla de disponibilidad por bloqueo de I/O en procesos externos congelados.
1. El Escenario del Problema
Durante las pruebas de estrés del enjambre S.A.T.I., se simuló un fallo de proceso hijo utilizando la señal SIGSTOP (congelamiento total de ejecución). A diferencia de un SIGKILL (donde el proceso muere y el SO cierra los descriptores de archivo), un proceso bajo SIGSTOP retiene sus descriptores pero deja de consumir datos de sus pipes.
2. El Hallazgo: El "Bug del Centinela Atrapado"
En la implementación inicial del Sidecar, el método de envío de mensajes era synchronized. Esto provocó un fallo en cascada:
- Bloqueo de Pipe: El Sidecar intentó escribir en el
stdindel proceso hijo congelado. El buffer del pipe se llenó y el hilo de escritura de Java quedó bloqueado a nivel de Kernel (I/O Wait). - Deadlock de Monitor: Al ser un método
synchronized, el hilo del Watchdog (el centinela) intentó obtener el lock para realizar un reinicio de emergencia, pero no pudo entrar porque el hilo de escritura estaba atrapado esperando que el proceso hijo despertara. - Resultado: El Sidecar quedó "zombie", incapaz de sanarse a sí mismo a pesar de tener un Watchdog activo.
3. Por Qué HTTP es Inferior en Este Escenario
En una arquitectura tradicional basada en REST/HTTP:
- El servidor HTTP consume recursos (puertos, sockets) mientras espera.
- Los timeouts de red a menudo dependen del stack de TCP del SO, lo que puede causar latencias impredecibles.
- Si el proceso se congela, el socket queda en
CLOSE_WAITo similar, llenando la tabla de descriptores del sistema.
4. La Solución S.A.T.I. (Grado Militar)
Rediseñamos el Sidecar para ser "Resiliente a Congelamiento" utilizando las capacidades de Java 25:
- Abandono de
synchronized: ImplementamosReentrantLockcontryLock(timeout). Si el túnel de datos no acepta información en 200ms, el hilo libera el control inmediatamente, evitando el deadlock. - Aislamiento del Watchdog: El método
hardReset()ahora tiene prioridad absoluta y puede ejecutarprocess.destroyForcibly()sin esperar la liberación de los locks de I/O de datos. - Hilos Virtuales: Usamos el modelo de concurrencia ligera de Java 25 para que cada intento de comunicación sea barato y no bloquee el sistema operativo, permitiendo que el Sidecar maneje miles de "túneles zombies" sin agotar la RAM.
5. Comparativa de Supervivencia (Matriz de Resiliencia)
Basado en las pruebas de la fase de implementación, el Sidecar con arquitectura Isolated Sentinel ha demostrado ser superior a las implementaciones estándar de microservicios.
| Escenario de Falla | Método de Ataque | Estado del Proceso | Resultado S.A.T.I. |
|---|---|---|---|
| Muerte Súbita | kill -9 (SIGKILL) | Proceso eliminado | Resucita: Detectado por rotura de Pipe. |
| Congelamiento | kill -STOP (SIGSTOP) | Proceso pausado | Resucita: Detectado por Timeout de I/O. |
| Bucle Infinito | Stress de CPU | Vivo / No responde | Resucita: Detectado por Watchdog Ping. |
| Deadlock Interno | Bloqueo de I/O | Zombie | Resucita: El Sentinel fuerza el Reset. |
6. Hoja de Trucos para Operadores (S.A.T.I. Quick Reference)
Comandos esenciales para gestionar el enjambre:
Verificar Salud del Enjambre:
# Monitorear latencia y estado de los 5 nodos en tiempo real
nats sub "fararoni.sati.registry"Simular Ataque de Congelamiento (Prueba de Resiliencia):
# Congela la víctima; el Watchdog debe detectarlo en < 5s
kill -STOP <PID_MCP_SERVER>El Botón de Pánico (Hard Reset Global):
# Fuerza el reinicio de TODOS los procesos STDIO simultáneamente
nats pub "fararoni.sati.control.panic" "HARD_REBOOT"7. Conclusiones y Filosofía de Diseño
El protocolo S.A.T.I. no solo actúa como un puente; actúa como un supervisor activo. Al tratar los fallos de I/O como eventos de primera clase, garantizamos que el Kernel Fararoni siempre tenga un camino de regreso al "Golden State", incluso cuando los procesos externos entran en estados de corrupción profunda.
El éxito de esta fase de implementación confirma que la soberanía tecnológica no se trata solo de tener el código, sino de tener el control absoluto sobre el ciclo de vida de la ejecución.
- Separación de Poderes: Al mantener a Java como el Gerente (lógica de control) y a Node.js como el Obrero (ejecución de herramientas), creamos un sistema donde el fallo de un componente no compromete la integridad del cerebro (Kernel).
- Eficiencia de Costos: No necesitamos balanceadores de carga costosos (F5, AWS ALB). La inteligencia de red reside en el Sovereign Event Bus y la inteligencia de recuperación en el Sidecar.
- Seguridad por Oscuridad: Al usar STDIO-TUNNEL, los servidores MCP son invisibles para la red. No hay puertos abiertos, no hay superficie de ataque externa.
Apéndice A: El "Momento de la Verdad"
Como se muestra en el script demo-ataque-enjambre.sh, la validación final post-ataque lanza una petición de lectura de archivo (read_file) al enjambre herido. El resultado: [EXITO] SISTEMA AUTOREPARABLE CONFIRMADO. Aunque el 40% de los nodos fueron atacados, la petición fue procesada por los nodos restantes en ~4.2ms, demostrando que el usuario final nunca percibe el caos interno.