Perché DEVE staccare da tty quando si scrive un daemon linux?

Question

Quando ho provato a scrivere un demone sotto Linux usando C, mi è stato detto che dovrei aggiungere codice seguente dopo forcella blocco di codice:

/* 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); 

La mia domanda è: C'è un must per fare le operazioni di cui sopra ?

Answer 1

È necessario dissociare il processo daemon dal terminale per evitare di inviare i segnali relativi al funzionamento del terminale (come SIGHUP quando termina la sessione terminale e potenzialmente SIGTTIN e SIGTTOU).

Si noti tuttavia che il modo di dissociare dal terminale utilizzando TIOCNOTTY ioctl è in gran parte obsoleto. Dovresti usare invece setsid().

Il motivo per cui un daemon lascia il gruppo di processi originale non è quello di ricevere i segnali inviati a quel gruppo. Si noti che setsid() posiziona anche il processo nel proprio gruppo di processi.

Answer 2

L'altra risposta è chiara e tecnicamente corretta (e quindi upvoted conseguenza).

Un'altra risposta è: "No, non scrivere il codice che si daemonizes."

usare al posto di un quadro di supervisione processo (come daemontools o runit o launchd) che si occupa di questo per voi.

Il server UNIX tradizionale è auto-daemonizing, e come tale si agita più di molte cose: la directory di lavoro corrente, gruppo di processi e l'indipendenza della sessione, maschere di segnale e la disposizione, radice di filesystem, privilegi, umask, descrittori di file aperti, ecc

Tuttavia, la maggior parte o tutti questi attributi di processo sono ereditati attraverso un exec(), il che significa che un processo server può essere generalmente "nato" con il gruppo di processi desiderato, la directory di lavoro, root, ecc. Non c'è molto bisogno di fare tutto da soli , anche se spesso dovrai ancora gestire le operazioni privilegiate e ottenere la revoca dei privilegi.

(Anzi, direi non c'è rischio a lungo termine per iscritto programmi di auto-daemonizing. Boilerplate "backgrounding" routine vengono copiati e incollati e frettolosamente porting ed estese, e il programmatore passa il tempo sul codice accessorio piuttosto che sul scopo principale del programma.)