Ho uno scenario in cui ho bisogno per trovare, se un processo è un demone processo o meno. Questo controllo deve essere fatto all'interno del processo. So che non ci sono diretti API di farlo. Ho esplorato queste opzioni.

1. ctermid () - questo può essere soccombente, come per le pagine man
2. int devtty; if ((devtty \u003d open ( "/ dev / tty", O_RDWR)) <0) allora è un demone. Esistono altri casi in cui questo non può essere vero?
3. Dal setsid () è usato per staccare da un terminale, forse getsid () può essere utilizzato per verificare processo leader del gruppo e sessione leader.
4. Se vuoi pid madre se è 1 o meno. Può un demone ppid avere un processo diverso da 1?

Ci sono altre opzioni? I dont sapere se esiste un modo migliore per farlo, ma quale sarebbe il modo più appropriato?

Demoni può avere qualsiasi ppid e un ppid di 1 è alcuna garanzia che sei un demone. Mi piace l'open / dev / tty idea. E 'portatile. Ma naturalmente non si può per altri motivi. Nessuno mai ha fatto un
rm / dev / tty
su uno qualsiasi dei vostri sistemi? Inoltre, il processo potrebbe essere di fd, ecc ancora è il modo migliore. A seconda del sistema Unix, vi può essere un modo non-portatile. Ottenere il codice sorgente per ps e vedere come si trova fuori questa roba. Ma questo è un sacco di problemi, di evitare di aprire / dev / tty. Vorrei andare con quella.

Vorrei costruire in una logica di contesto, in modo che si può essere sicuri. Ad esempio, SIGHUP è un vettore non-zero se un processo è avviato. E 'buona pratica nullo il vettore dopo la forcella / exec (nel bambino, naturalmente), ovviamente, per evitare l'umiliazione di avere uno bello demone uscire quando il codice di avviamento-termina alto. Così, quindi, il test potrebbe essere "è il mio SIGHUP vettore NULL?" e di conseguenza il processo. Utilizzare il sistema operativo di strutture di buon fine, e lasciare che aiutare a identificare il tuo contesto, anche.

Qualsiasi processo custodito dal segnale SIGHUP nohup come processo di controllo e staccati dal terminale avrà una ppid di 1, ma non sono daemonized.

Come su questo - per verificare le autorizzazioni per il mascheramento? So che non è una prassi standard che deve essere seguita daemonizing prima di un processo, ma la sua più di una pratica.

Non è vero. Qualsiasi momento demone che succede da ignorare SIGHUP forchette, si crea un controesempio alla presente dichiarazione. (senza forcella init potrebbe creare un controesempio, ma non ignora hop)
In realtà ogni processo che avviene per rispondere a tali criteri sono demoni. N. terminali di controllo, il processo è un demone. O meno di un processo è un demone non ha nulla a che fare con la ppid o segnali di ciò che si ignora.

Con la maggior parte delle versioni di Unix, quando si accede alla console di sistema, il ppid di shell di login sarà 1. Prima che l'aumento del TCP / IP di ogni ppid la shell di login è stato di 1. Nessuno di questi gusci di accesso sono i demoni, che hanno tutti i terminali di controllo. Si può avere ancora altri getty linee in / etc / inittab. Ciascuna di queste è un potenziale shell interattiva con un ppid di 1. Ma la maggior parte degli altri bambini generato da init non aprire ttys e restano demoni.

Quando un processo uscite, i suoi figli diventano di proprietà di init. Ciò non di impatto se non quelle che i bambini sono i demoni. Alcuni sono. Alcuni non lo sono.

cron non avrà un pid del 1. Ogni volta che genera un processo di cron, che è un nuovo processo demone. Ognuno di questi demoni non ha ancora una ppid di 1 ... loro ppid sarà rivolto a cron.

Quando è necessario determinare se un processo è un demone o no, il ppid è completamente irrilevante. Demoni e demoni non possono avere un ppid di 1. Demoni e demoni non possono avere un ppid diversa.

Demoni talvolta scegliere di non ignorare SIGHUP. Entrambi inetd e init si sono esempi di demoni che sono in ascolto per un HUP. Quando avrete una sola, si riconfigura stessi. Ma è più comune per un demone da ignorare HUP.

E 'davvero molto semplice.
Demoni non hanno il controllo del terminale.
Non demoni hanno un terminale di controllo.

Esempi di cose che non incidono su un processo ' demone stato ...
pid
ppid
segnale maschera

Concordato.
ppid non importa.

Ma che dire di un processo iniziato come nohup processo di controllo e staccati dal terminale?
Non ha allegato terminale, non credo che possa essere chiamato a demone.

Iniziata come una nohup o meno non importa. La maggior parte dei demoni ben scritto esplicitamente ignorare i segnali che vogliono ignorare e che praticano l'installazione per i segnali che si desidera ricevere.

Ma se si è staccata dal terminale di controllo, è un demone. Questo è esattamente ciò che accade quando si riavvia inetd cron o dalla riga di comando. Poiché non ci si pensa che i processi di controllo, senza i terminali sono demoni, qual è la sua definizione di un demone?