Quais são as diferenças práticas do ponto de vista de sysadmin ao implantar serviços em um sistema baseado em unix?
A maneira tradicional de daemonizing é:
fork()
setsid()
close(0) /* and /dev/null as fd 0, 1 and 2 */
close(1)
close(2)
fork()
Isso garante que o processo não esteja mais no mesmo grupo de processos que o terminal e, portanto, não será eliminado junto com ele. O redirecionamento de IO é fazer com que a saída não apareça no terminal.
Para um daemon, o que você quer é um processo que não tenha nenhum empecilho a nada. No mínimo, você quer que ele esteja em sua própria sessão, não seja anexado a um terminal, não tenha nenhum descritor de arquivo herdado do pai aberto a nada, não tenha um pai cuidando de você (que não seja o init) tenha o atual diretório em / para não evitar um umount ...
Para desanexar de um terminal, crie uma nova sessão, no entanto, para criar uma sessão, você não deve ser um líder de grupo (ou sessão), portanto, o melhor é criar um novo processo. Supondo que o pai saia, isso também significa que o processo não terá mais um pai e será adotado pelo init. Então, você chdir("/") fecha todos os descritores de arquivos possíveis.
Como esse processo é um líder de sessão, existe o risco de que, se ele abrir um dispositivo terminal, ele se torne o processo de controle desse terminal. Bifurcando uma segunda vez garante que isso não aconteça.
No outro extremo, & amp ;, em shells interativos, forks e cria um novo grupo de processos (para não estar no grupo de processos de primeiro plano do terminal), e em shells não interativos, bifurca um processo e ignora o SIGINT em isto. Ele não desanexa do terminal, não fecha descritores de arquivos (embora alguns shells reabrem stdin para /dev/null ) ...
A diferença entre executar um programa / processo como um daemon e incluí-lo no plano de fundo usando o "e" comercial é basicamente relacionada à propriedade.
Na maioria das vezes, o processo pai de um daemon é o processo init (o primeiro processo a ser iniciado em um sistema Unix), o daemon sendo filho desse processo significa que ele não é sob seu controle direto como um usuário não privilegiado. Enquanto, por outro lado, forjar um programa / processo para o background significa que você pode, a qualquer momento, chamá-lo de volta para o primeiro plano e / ou matá-lo.
Com command & Seu processo será eliminado por um sinal SIGHUP quando o pai morrer.
Os administradores de sistemas têm acesso a algumas soluções alternativas.
Em um sistema bash, você pode usar:
(trap '' HUP; command) &
Isso abre um subshell, captura o sinal HUP com um manipulador vazio e oe comercial / bifurca-o.
A saída ainda pode ser redirecionada para o tty errado. Ou se perca.
Você pode corrigir isso com &>command.out , 1>output.out ou 2>errors.out
Você também pode ter acesso, na maioria dos sistemas, ao comando nohup .
nohup simplifica muito esse processo. É bastante normal, mas descobri que muitas distribuições de ARM embarcadas do busybox estão faltando. Você acabou de escrever:
nohup command &
.. e pronto. A saída é redirecionada, IIRC, para nohup.out , mas esse nome de arquivo pode ser alterado com uma opção.