Tenho um cenário em que eu preciso para descobrir se um processo é um daemon processo ou não. Essa verificação deve ser feita dentro do processo. Sei que não existem directo API's para o fazer. Tenho explorou estas opções.

1. ctermid () - este pode ser vencida por enquanto as páginas man
2. int devtty; if ((devtty \u003d open ( "/ dev / tty", O_RDWR)) <0), então é uma daemon. Existem outros casos, quando este não pode ser verdade?
3. Desde setsid () é usado para separar a partir de um terminal, talvez getsid () pode ser usado para verificar a existência de processo grupo líder e líder sessão.
4. Olha se progenitor pid é 1 ou não. Pode um daemon ppid tem um processo diferente de 1?

Existem mais opções? Eu não sei se existe uma maneira melhor de fazer isso, mas qual seria a forma mais adequada?

Daemons podem ter qualquer ppid e um ppid de 1 é nenhuma garantia de que você é um daemon. Eu gosto de abrir / dev / tty idéia. It's portáteis. Mas é claro que pode falhar por outras razões. Ninguém nunca fez um
rm / dev / tty
em qualquer um dos seus sistemas? Além disso, o processo poderia ser fora de fd's, etc Ainda é o melhor caminho. Dependendo do sistema Unix, pode haver uma maneira não-portáteis. Obtenha o código fonte para ps e ver como ele acha isto. Mas isso é um monte de problemas para evitar a abertura de / dev / tty. Gostaria de ir com isso.

Gostaria de construir uma lógica no contexto de modo que você pode ter certeza. Por exemplo, SIGHUP é um vetor não-zero, quando um processo é iniciado. É uma boa prática para o vetor nulo depois de um garfo / exec (na criança, é claro), obviamente para evitar a humilhação de ter um bom daemon fechar quando o código-starter superior termina. Então, então, o teste poderá ser "é o meu vetor SIGHUP NULO?" e do processo de conformidade. Use o seu SO facilidades para uma boa finalidade, e deixá-los ajudar a identificar o seu contexto, também.

Can a daemon process have a ppid other than 1 ?

Não é verdade. Qualquer momento qualquer daemon o que acontece ao ser ignorando sighup garfos, ele cria um contra-exemplo para esta afirmação. (init poderia garfo, sem criar um contra-exemplo, mas ele nunca ignora hup)
Na verdade qualquer processo que acontece para satisfazer estes critérios são demónios. Não controlo terminal, o processo é um daemon. Quer ou não um processo é um daemon não tem nada a ver com os sinais ppid ou o que é ignorar.

Com a maioria das versões do Unix quando você faz logon no console do sistema, o seu login ppid do reservatório será de 1. Antes da ascensão do TCP / IP de todas as ppid login reservatório foi de 1. Nenhuma destas login cascas são demónios, todos eles têm controle terminais. Você ainda pode ter outras Getty linhas em / etc / inittab. Cada uma destas linhas é um reservatório com um potencial interativo ppid de 1. Mas a maioria das outras crianças desovado pelo init não abra ttys e permanecer demónios.

Quando um processo saídas, as crianças tornam-se propriedade de init. Isto não se do impacto dessas crianças não são demónios. Alguns são. Algumas não são.

cron não terá um pid de 1. Cada vez cron desova um processo, que é um novo processo daemon. Cada um destes daemons não terá um ppid de 1 ... sua ppid será apontada para cron.

Quando você precisa para determinar se um processo é um daemon ou não, o ppid é completamente irrelevante. Demónios e demónios não podem ter uma ppid de 1. Demónios e demónios não podem ter uma ppid excepto uma.

Daemons vezes para escolher não sighup ignorar. Tanto inetd e init própria são exemplos de demónios que se escuta por um HUP. Quando ficam um, eles próprios reconfigurar. Mas é mais comum para um daemon ignorando a ser HUP.

Realmente é muito simples.
Demónios não têm controle de terminal.
Non-daemons têm um controle de terminal.

Exemplos de coisas que não têm qualquer relação com um processo " daemon estado ...
pid
ppid
sinal máscara

Daemons have no controlling terminal.
Non-daemons have a controlling terminal.

Iniciado como um nohup ou não, não importa. A maioria dos demónios vão bem escrito explicitamente ignorar sinais de que pretende ignorar e instalar manipuladores de sinais de que deseja receber.

Mas se ela é separada do controle do terminal, que é um daemon. Isto é exactamente o que acontece quando você reiniciar cron inetd ou na linha de comando. Desde que você não pensa que os processos que não controlam terminais são demónios, qual é a sua definição de um daemon?