Início / unix / Perguntas / 504342
Accepted
arif
Asked: 2019-03-05 11:43:30 +0800 CST

Por que a bifurcação é usada em um arquivo de unidade de um serviço?

  • 772

Meu arquivo de unidade nginx está seguindo,

[root@arif ~]# cat /usr/lib/systemd/system/nginx.service
[Unit]
Description=The nginx HTTP and reverse proxy server
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
# Nginx will fail to start if /run/nginx.pid already exists but has the wrong
# SELinux context. This might happen when running `nginx -t` from the cmdline.
# https://bugzilla.redhat.com/show_bug.cgi?id=1268621
ExecStartPre=/usr/bin/rm -f /run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
KillSignal=SIGQUIT
TimeoutStopSec=5
KillMode=process
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Aqui, na [Service]porção, o valor de Typeé igual ao forkingque significa daqui ,

O processo iniciado com ExecStart gera um processo filho que se torna o processo principal do serviço. O processo pai é encerrado quando a inicialização é concluída.

Minhas perguntas são,

  • Por que um serviço faz isso?
  • Quais são as vantagens de fazer isso?
  • O que há de errado é Type=simpleou outras opções semelhantes?
linux systemd

2 respostas

  1. Best Answer

    Por que um serviço faz isso?

    Os serviços geralmente não fazem isso, na verdade. Além do fato de que não é uma boa prática, e a ideia de "dæmonização" é realmente falaciosa, o que os serviços fazem não é o que o forkingprotocolo exige . Eles entendem o protocolo errado, porque na verdade estão fazendo outra coisa , que está sendo encaixada no forkingprotocolo, geralmente desnecessariamente.

    Quais são as vantagens de fazer isso?

    Não há nenhum. Existem protocolos de notificação de prontidão melhores e ninguém fala esse protocolo corretamente. Esta unidade de serviço não está fazendo isso porque é vantajoso.

    O que há de errado é Type=simpleou outras opções semelhantes?

    Nada. De fato, geralmente é o uso do forkingprotocolo de prontidão que está errado. Esta não é a melhor prática, como afirmado em outras respostas. Muito pelo contrário.

    O simples fato é que este é o melhor de um trabalho ruim, um truque para lidar com um comportamento do nginx que ainda não pode ser desligado. A maioria dos softwares de serviço hoje em dia, graças a um quarto de século de incentivo do IBM SRC, daemontools e outros mundos sérios de gerenciamento de serviços, ganhou opções para, ou mesmo mudou seus comportamentos padrão, não tentando tolamente "daemonizar" algo que já está no contexto daemon .

    Este ainda não é o caso do nginx, no entanto. daemon offnão funciona, infelizmente. Assim como muitos softwares costumavam confundir erroneamente o modo "não-dæmonize" com o modo de depuração (mas muitas vezes não o fazem mais, hoje em dia), o nginx infelizmente o confunde com outras coisas, como não manipular seus sinais de controle. As pessoas têm pressionado por isso há 5 anos, até agora.

    Leitura adicional

    • 7

  2. Desde que o serviço em questão não suporte especificamente o sistema de mensagens quando ele terminar de inicializar (consulte man systemd-notifyRecursos), o método de bifurcação é usado como o meio tradicional de notificação: Enquanto o processo pai estiver vivo, o status do serviço relatado por systemctl statuspermanece em start.
    Ele muda para runningsomente após a saída do processo pai. O processo pai de um serviço de daemon tradicional sai somente depois que o processo filho termina sua configuração e está pronto para ser usado.

    Esse mecanismo é necessário se houver serviços dependentes aguardando que o serviço em questão fique pronto para uso. Um serviço que não suporta o systemdmétodo específico de notificação seria iniciado sem usar o mecanismo tradicional de bifurcação do daemon, o status do serviço mudaria para runningimediatamente e quaisquer serviços dependentes seriam iniciados imediatamente após o serviço em questão, antes de estar pronto para ser usado.

    Esta razão é explicada com mais detalhes no Debian Bug #728015, que já está vinculado na resposta do JdeBP.
    Esse motivo também é o motivo pelo qual esse bug foi fechado como wontfix.

    • 0

relate perguntas