El patrón double-fork explicado: cómo los demonios en POSIX evitan heredar una terminal de control

En los sistemas POSIX, crear un demonio —un proceso sin terminal de control— requiere algo más que invocar fork(). El artículo explica el patrón conocido como double-fork, descubierto por el autor mientras construía zmx, su herramienta de gestión de sesiones. El recorrido comienza definiendo qué es un demonio: un proceso que pertenece a una sesión sin terminal de control, a diferencia de los procesos enviados al fondo con Ctrl+Z+bg o &, que siguen vinculados al terminal. Tras repasar cómo fork() duplica un proceso y devuelve valores distintos a padre e hijo, el texto introduce las nociones de sesión, grupo de procesos y terminal de control, apoyándose en diagramas ASCII que muestran la jerarquía resultante de cada bifurcación. A continuación aclara por qué un único fork no basta: tras crear un proceso hijo y llamar a setsid() para convertirlo en líder de sesión, ese hijo aún podría abrir un dispositivo de terminal y adquirirlo como terminal de control, quedando expuesto a señales como SIGINT o SIGHUP. El segundo fork garantiza que el nieto nunca sea líder de sesión y, por tanto, no pueda hacerse con una terminal, sea cual sea el comportamiento del sistema POSIX subyacente. El artículo señala también que esta técnica es considerada algo paranoica en Linux, pero es la forma portátil de asegurar el aislamiento. Además del doble fork, un demonio robusto debe limpiar lo heredado: redirigir stdin, stdout y stderr a /dev/null para evitar bloqueos en pipes de test harnesses, y cerrar descriptores heredados del 3 al 64. Por último, se discute por qué zmx no recurre a supervisores del sistema como systemd, runit u openrc: requiere portabilidad entre Linux y macOS y un daemonizado automático al adjuntarse a la sesión.