Me pregunto por qué la gente llama a fork() dos veces y por qué la primera llamada se realiza antes setsid() .
Sí, no se crea ninguna sesión nueva si la persona que llama ya es un líder de grupo de proceso. Pero, ¿qué pasa si simplemente no hago que el (abuelo) padre sea un líder del grupo de procesos? ¿Quién lo haría por mí (sin preguntarme)? (OK, tal vez 1llum1n4t1, Sc13nt0l0gy, la NSA, ... ;) )
Sí, el primer niño debe salir inmediatamente para no crear un proceso zombie. ¿Pero no podría el (abuelo) padre simplemente salir después de bifurcarse? ¿O una o dos fprintf(stderr,... o write(2,... ) (como "inició con éxito el daemon xy") serían tan importantes ? (¿Y no podría prevenir a los zombis de otra manera?)
Considerándolo todo, ¿realmente se requiere esta "magia" de doble fork() (para no tener problemas)? ¿O es solo tradición o la llamada "mejor práctica" (como evitar goto )? ¿O simplemente garantiza que el demonio funcione en plataformas "históricas" (por supuesto, me refiero a "demasiado antiguas para su uso en entornos de producción") como SVr4, BSD 3, RHEL 2 o algunas incrustadas de 32 bits?
La primera llamada a fork(2) asegura que el proceso no sea un líder de grupo, por lo que es posible que ese proceso cree una nueva sesión y se convierta en un líder de sesión. Hay otras razones para la primera fork(2) : si el daemon se inició como un comando de shell, tener la bifurcación del proceso y la salida principal hace que el shell vuelva a su indicador y espere más comandos.
La segunda fork(2) está ahí para garantizar que el nuevo proceso no sea un líder de sesión, por lo que no podrá (accidentalmente) asignar una terminal de control, ya que se supone que los demonios nunca tienen una terminal de control. Acerca de la segunda bifurcación, aquí hay una cita de Programación avanzada en el entorno UNIX , Capítulo 13 (Procesos de Daemon):
En los sistemas basados en System V, algunas personas recomiendan volver a llamar a fork en este punto, terminar el padre y continuar con el daemon en el hijo. Esto garantiza que el daemon no sea un líder de sesión, lo que le impide adquirir una terminal de control bajo las reglas de System V. Como alternativa, para evitar adquirir un terminal de control, asegúrese de especificar O_NOCTTY cada vez que abra un dispositivo de terminal.
La Sección 13.3 de ese libro describe muchas más reglas y patrones que se utilizan al demonizar un proceso, vale la pena leerlo, si puede.