O que é associação de pais e mestre no Linux
Processos no Linux vivem em uma hierarquia simples mas com consequências práticas que muita gente ignora até cometer o erro. O conceito de "pai" e "mestre" não é um comando único — é a relação entre processos criados via fork() e o líder da sessão que controla o terminal. Quando você roda um comando no terminal, aquele processo é filho do shell e membro do mesmo grupo de processos. O shell, por sua vez, é o líder da sessão (session leader), e isso define quem herda o terminal de controle. A confusão comum é achar que o processo pai (pai = parent) e o mestre (session leader) são a mesma coisa. Não são. Um processo pode ser pai de outro sem ser o mestre da sessão, e o mestre pode não ter nenhum filho direto no momento da execução. A distinção importa quando você precisa desconectar um processo do terminal sem matá-lo.
Como funciona a associação de pais e mestre na prática
Vamos ao que realmente acontece quando você executa algo. Suponha que você rode ./minha_app & no bash. O bash cria um processo filho via fork() e executa seu programa. Seu processo agora tem o bash como pai (PID do bash aparece na coluna PPID). O bash continua sendo o session leader. Se você fechar o terminal, o bash recebe SIGHUP, propaga para todos os processos do grupo, e seu programa morre junto — a menos que algo tenha sido configurado antes. O truque que a maioria das pessoas usa é nohup ou disown. Ambos fazem coisas diferentes. nohup redefine o handler de SIGHUP para SIG_IGN antes do exec(), o que impede que o sinal mate o processo. Disown retira o processo da tabela de jobs do shell atual, mas não redefine o handler de sinal. O problema é que disown sozinho não garante sobrevivência se o shell receber SIGHUP de outra fonte, como um gerenciador de sessões tmux ou screen.
Eu tive um caso específico onde um serviço rodava dentro de um tmux, e quando o servidor era reinicializado, o process manager do sistema enviava sinal para o processo pai (o shell do tmux). O disown não salvou porque o sinal chegava pelo controlador de terminal, não pela tabela de jobs. A solução foi usar um wrapper com setsid antes do comando: setsid ./minha_app </dev/null >>log.txt 2>&1 &. O setsid cria uma nova sessão, tornando o processo o session leader de si mesmo, completamente isolado do terminal original. Aí sim ele sobreviveu ao reboot. Se você precisa apenas testar se a associação está correta antes de deixar rodando, use ps -o pid,ppid,pgid,sid,comm para ver a árvore completa. O campo SID mostra o session ID. Processos do mesmo SID compartilham o terminal de controle. Se o SID do seu processo for diferente do SID do shell que o iniciou, ele já está isolado.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Pegadinhas que ninguém conta
A primeira pegadinha é acreditar que nohup é suficiente para qualquer cenário. Ele funciona bem para processos simples iniciados diretamente do shell interativo, mas falha em ambientes containerizados onde o PID 1 é um entrypoint script e não um shell. Nesse caso, o processo filho herda o comportamento do entrypoint, e o nohup não tem efeito porque o signal mask já está definido de outra forma pelo runtime. A segunda é confundir grupo de processos com sessão. Duas árvores de processos com o mesmo PGID podem estar em SIDs diferentes e, portanto, ter terminais de controle distintos. O comando ps -eo pid,ppid,pgid,sid,stat,comm mostra tudo em uma linha só. Se o estado (STAT) mostrar "s" como primeiro caractere, o processo é session leader. Isso é útil para identificar rapidamente quem é o mestre em meio a dezenas de processos.
Um limitante real dessa abordagem é que processos desassociados perdem a capacidade de receber input do terminal original. Se seu programa precisa de interatividade posterior, você vai precisar redirecionar stdin de forma explícita ou usar um pseudo-terminal dedicado, o que complica o setup e muitas vezes exige bibliotecas como ptyprocess ou script para manter o dispositivo funcionando. Para cenários onde você precisa de sobrevivência a longo prazo com monitoramento, o ideal é usar um gerenciador de serviços como systemd ou supervision. Eles criam a associação correta desde o início, com restart policy, logging estruturado e controle granular de sinais. O setsid e o nohup são soluções de emergências, não de produção.
Se o objetivo é apenas testar uma associação específica, o procedimento mais rápido é: iniciar um processo filho, verificar o SID com ps, enviar SIGHUP para o session leader original com kill -HUP, e observar se o processo filho continua rodando. Se continuar, a desassociação funcionou. Se morrer, ainda há ligação de terminal ou grupo de processos que precisa ser quebrada.
Resumo direto para associação de pais e mestre
Conhecer a diferença entre parent, process group e session leader evita perda de tempo com processos que morrem quando o terminal fecha. O comando setsid resolve o isolamento completo. O nohup resolve o caso mais simples. O disown resolve o manejo interno do shell. Nenhum deles é bala de prata, e cada um tem um ponto de falha conhecido. Escolha conforme o contexto, teste com ps antes de confiar, e migre para systemd quando o ambiente pedir.
