c - son - systemd linux

¿Por qué DEBE separarse de tty al escribir un demonio de Linux?

Question

Cuando intenté escribir un demonio bajo Linux usando C, me dijeron que debía agregar el siguiente código después del bloque de código de bifurcación :

/* Preparations */
...
/* Fork a new process */
pid_t cpid = fork();
if (cpid == -1){perror("fork");exit(1);}
if (cpid > 0){exit(0);}
/* WHY detach from tty ? */
int fd = open("/dev/tty", O_RDWR);
ioctl(fd, TIOCNOTTY, NULL);
/* Why set PGID as current PID ? */
setpgid(getpid(), 0);

Mi pregunta es: ¿hay que hacer las operaciones anteriores?

Answer 1

Debe desasociar su proceso de daemon del terminal para evitar que se le envíen señales relacionadas con el funcionamiento del terminal (como SIGHUP cuando finaliza la sesión del terminal y potencialmente SIGTTIN y SIGTTOU).

Sin embargo, tenga en cuenta que la forma de desvincularse del terminal utilizando TIOCNOTTY ioctl es en gran parte obsoleta. Deberías usar setsid() lugar.

La razón por la que un demonio abandona su grupo de proceso original es no recibir las señales enviadas a ese grupo. Tenga en cuenta que setsid() también coloca su proceso en su propio grupo de procesos.

Answer 2

La otra respuesta es clara y técnicamente correcta (y, por lo tanto, voté en consecuencia).

Otra respuesta es: "No, no escriba código que se desmonte a sí mismo".

En su lugar, use un marco de supervisión de procesos (como daemontools o runit o launchd ) que se encargue de esto por usted.

El servidor tradicional de UNIX es auto-demanizante, y como tal se preocupa por muchas cosas: directorio de trabajo actual, independencia de sesión y grupo de procesos, máscaras y disposición de señales, raíz del sistema de archivos, privilegios, umask, descriptores de archivos abiertos, etc.

Sin embargo, la mayoría o la totalidad de estos atributos de proceso se heredan a través de un exec() , lo que significa que un proceso de servidor normalmente puede "nacer" con el grupo de procesos, el directorio de trabajo, la raíz, etc. deseados. aunque a menudo todavía tendrá que administrar las operaciones privilegiadas y la revocación de privilegios usted mismo.

(De hecho, yo diría que existe un riesgo a largo plazo al escribir programas de auto-daemonización. Las rutinas de "fondo" de repetición se copian y pegan y aprovisionan y amplían rápidamente, y el programador dedica tiempo al código auxiliar en lugar de al propósito principal del programa. )