Hablando estrictamente, el doble tenedor no tiene nada que ver con volver a criar al demonio como hijo de init. Todo lo que se necesita para volver a criar al hijo es que el padre debe salir. Esto se puede hacer con un solo tenedor. Además, hacer una doble bifurcación por sí solo no vuelve a crear el proceso del demonio init; los padres del demonio deben salir. En otras palabras, el padre siempre sale cuando se bifurca un demonio apropiado para que el proceso del demonio se vuelva a parear init.
Entonces, ¿por qué el doble tenedor? POSIX.1-2008 La sección 11.1.3, " El terminal de control ", tiene la respuesta (énfasis agregado):
El líder de sesión asigna el terminal de control para una sesión de una manera definida por la implementación. Si un líder de sesión no tiene terminal de control y abre un archivo de dispositivo de terminal que no está asociado con una sesión sin usar la O_NOCTTYopción (ver open()), se define la implementación si el terminal se convierte en el terminal de control del líder de sesión. Si un proceso que no es un líder de sesión abre un archivo de terminal, o O_NOCTTYse usa la opción open(), entonces ese terminal no se convertirá en el terminal de control del proceso de llamada .
Esto nos dice que si un proceso de demonio hace algo como esto ...
int fd = open("/dev/console", O_RDWR);
... entonces el proceso del demonio podría adquirir /dev/consolecomo su terminal de control, dependiendo de si el proceso del demonio es un líder de sesión, y dependiendo de la implementación del sistema. El programa puede garantizar que la llamada anterior no adquirirá un terminal de control si el programa primero asegura que no es un líder de sesión.
Normalmente, cuando se inicia un demonio, setsidse llama (desde el proceso secundario después de llamar fork) para disociar el demonio de su terminal de control. Sin embargo, llamar setsidtambién significa que el proceso de llamada será el líder de la sesión de la nueva sesión, lo que deja abierta la posibilidad de que el demonio pueda volver a adquirir un terminal de control. La técnica de doble tenedor garantiza que el proceso del demonio no sea el líder de la sesión, lo que garantiza que una llamada a open, como en el ejemplo anterior, no dará como resultado que el proceso del demonio vuelva a adquirir un terminal de control.
La técnica del doble tenedor es un poco paranoica. Es posible que no sea necesario si sabe que el demonio nunca abrirá un archivo de dispositivo terminal. Además, en algunos sistemas puede no ser necesario incluso si el demonio abre un archivo de dispositivo terminal, ya que ese comportamiento está definido por la implementación. Sin embargo, una cosa que no está definida por la implementación es que solo un líder de sesión puede asignar el terminal de control. Si un proceso no es un líder de sesión, no puede asignar un terminal de control. Por lo tanto, si desea ser paranoico y estar seguro de que el proceso del demonio no puede adquirir accidentalmente un terminal de control, independientemente de los detalles específicos de la implementación, entonces la técnica de doble tenedor es esencial.