É uma boa prática criar um job em segundo plano dentro de um script de init se o processo não puder se daemonizar sozinho?

Question

Sou relativamente novo em * nix e descobri a necessidade de descartar vários processos, que devem ser executados 100% do tempo. para fundo usando & .

Eu uso a seguinte linha em um script init.d para fazer isso (rodando como o usuário user :

su -c 'process arg1 arg2 -w - | process2 arg1 -r - &' user

(onde -w escreve para e -r lê de STDOUT, STDIN)

Especificamente, sei que isso geralmente não é aceitável, já que os processos não são bem protegidos da influência externa.

É aceitável criar trabalhos em segundo plano para "serviços"?

Devo usar um FIFO / pipe nomeado para lidar com a comunicação entre processos?

Em caso afirmativo, devo ainda criar os dois processos como trabalhos em segundo plano? Isso é estável?

Para detalhes, consulte este tópico da lista de discussão .

Obrigado,

Matt

    

Answer 1

Specifically, I know this is not generally acceptable, as the processes aren't well shielded from outside influence.

Is it acceptable to create background jobs for "services?"

Se não houver outra maneira (isto é, o serviço não vai funcionar por conta própria), então provavelmente sim. O start-stop-daemon do Debian tem um parâmetro --background para tais casos:

   -b, --background
          Typically used with programs that don't  detach  on  their  own.
          This option will force start-stop-daemon to fork before starting
          the  process,  and  force  it  into  the  background.   WARNING:
          start-stop-daemon  cannot  check  the exit status if the process
          fails to execute for any reason. This is a last resort,  and  is
          only  meant  for  programs  that either make no sense forking on
          their own, or where it's not feasible to add the code  for  them
          to do this themselves.

    

Answer 2

Como a primeira pergunta já foi respondida, vou me concentrar nos dois últimos.

Alguns dias atrás, lutei sobre um problema semelhante: tive que iniciar alguns processos via pipe a partir de /etc/init.d scripts. Para resolver isso, eu dei uma olhada no RHEL6 ( daemon e killproc de /etc/init.d/functions ) e Debian ( start-stop-daemon ). O que eu aprendi foi que ambos não lidavam com tubos (muito bem). Mesmo que de alguma forma fosse possível iniciá-los, havia grandes problemas em pará-los. Por isso, escrevi uma pequena ferramenta pipexec . Este programa inicia um canal de programas, mas se comporta como um programa. Exemplo: quando um SIGTERM é enviado para pipexec , ele mata todos os filhos e depois ele mesmo. Também o manuseio de arquivos pid é suportado - o que lhe dá uma vida fácil ao integrar com RHEL6 daemon e killproc .

Should I instead use a FIFO/named pipe to handle the interprocess communication? If so, should I still create both processes as background jobs? Is this stable?

Eu também pensei sobre isso - mas para mim isso é complicado e eu não tive uma boa experiência quando se trata de fifos sobre estabilidade e confiabilidade (talvez este seja o meu problema - mas, portanto, eu raramente os uso ;-))

Eu integrei pipexec com RHEL6 e não há problemas; apenas corre.

Atenciosamente - Andreas