Por que um processo deamon precisa de um novo sid?

0

Extraído de: link

From here, the child process must get a unique SID from the kernel in order to operate. Otherwise, the child process becomes an orphan in the system.

Qual é o problema se o processo filho se tornar órfão? Por que precisa do seu próprio sid?

    
por Federico Ponzi 12.01.2016 / 21:51

1 resposta

1

* Processos Nix são identificados por um PID (ID do processo), um PPID (PID pai), um GID (ID do Grupo) e um SID (ID da Sessão). Você pode vê-los com o comando

 ps  xao pid,ppid,pgid,sid,comm

(isso inclui o campo command , ou seja, o comando que deu origem ao processo).

O PID e o PPID são fáceis de entender; o GID é usado para permitir que uma interrupção atinja todos os processos pertencentes ao mesmo grupo: suponha que você esteja fazendo

find / -type f -name '*.pdf' | sort | less

e você deseja suspend deste comando ( Ctrl + Z ) você precisará suspender todos eles; para permitir isso, eles pertencem ao mesmo GID e a interrupção é entregue a todos os processos com o mesmo GID.

O SID (ID da sessão) é o PID do processo que cria uma sessão. Todos os processos criados posteriormente na mesma sessão herdam esse SID, embora possam ter identificações de grupo e PPIDs distintos, e eles certamente têm PIDs distintos.

Quando a sessão em questão termina (por exemplo, através de um logout), o kernel mata todos os processos com o mesmo SID, pertencente à sessão em questão. Isso é feito por razões óbvias: os processos deixados aguardariam pela entrada que não pode mais chegar, ou eles estariam entregando mensagens de saída ou de erro que ninguém examinaria.

Para um serviço (minha resposta anterior não levou em consideração que você está discutindo exatamente um serviço, desculpe a minha falta de atenção) para sobreviver ao logout da sessão que o iniciou, ele não pode ser deixado com o SID da sessão original, para que não seja ceifada pelo kernel no logout. Daí a necessidade de um novo SID. Se você não atribuir um novo SID, ele herdará o da sessão que o executa e será cancelado sempre que a sessão for fechada, o que provavelmente será muito mais curto do que o tempo que você deseja que um serviço dure.

Há outro padrão (mas ainda assim fofo) na página que você mencionou acima: o fork . Isso também faz parte da estratégia para o daemon sobreviver ao desaparecimento de seu ambiente de origem. Você provavelmente notou que o daemon primeiro se bifurca em seu processo pai, então ele imediatamente fecha o processo pai antes de começar a trabalhar. Por quê? Porque, quando um terminal é fechado, ele envia um sinal SIGHUP para seu processo de controle, o shell. Isso geralmente faz com que todo o processo anexado a este shell morra, pois o shell irá retransmitir o SIGHUP que recebeu para todos os seus jobs. Mas o shell não mantém o controle de seus netos , portanto o daemon sobrevive ao fechamento do terminal de onde se origina.

Separar o daemon da Sessão e do terminal é essencial para sua sobrevivência, uma vez que qualquer um deles desapareça.

    
por 13.01.2016 / 00:01

Tags