☰

É uma boa prática criar um trabalho em segundo plano dentro de um script de inicialização se o processo não puder ser daemonizado?

tag-icon • tag-icon init-script daemon
É uma boa prática criar um trabalho em segundo plano dentro de um script de inicialização se o processo não puder ser daemonizado?

Sou bastante novo no *nix e me deparei com a necessidade de eliminar vários processos, que deveriam ser executados 100% do tempo. para segundo plano usando &.

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

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

(onde -w grava e -r lê STDOUT, STDIN)

Especificamente, sei que isso geralmente não é aceitável, pois os processos não estão bem protegidos contra influências externas.

É aceitável criar empregos em segundo plano para “serviços”?

Em vez disso, devo usar um canal FIFO/nomeado para lidar com a comunicação entre processos?

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

Para obter detalhes, consulteeste tópico da lista de discussão.

Obrigado,

Matt

Responder1

Especificamente, sei que isso geralmente não é aceitável, pois os processos não estão bem protegidos contra influências externas.

É aceitável criar empregos em segundo plano para “serviços”?

Se não houver outra maneira (ou seja, o serviço não será bifurcado por conta própria), provavelmente sim. O Debian start-stop-daemontem um --backgroundparâmetro 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.

Responder2

Como a primeira pergunta já foi respondida, vou me concentrar nas duas últimas.

Alguns dias atrás eu lutei com um problema semelhante: tive que iniciar alguns processos via pipe a partir de /etc/init.dscripts. Para resolver isso, dei uma olhada no RHEL6 ( daemone killprocde /etc/init.d/functions) e no Debian ( start-stop-daemon). O que aprendi foi que ambos não manuseavam canos (muito bem). Mesmo que fosse possível iniciá-los, houve grandes problemas para interrompê-los. Portanto eu escrevi uma pequena ferramentapipexec. Este programa inicia um canal de programas, mas se comporta como um programa. Exemplo: quando um SIGTERMé enviado, pipexecele mata todos os filhos e depois ele mesmo. Também há suporte para manipulação de arquivos pid - o que facilita a integração com RHEL6 daemone killproc.

Em vez disso, devo usar um canal FIFO/nomeado para lidar com a comunicação entre processos? Em caso afirmativo, ainda devo criar os dois processos como trabalhos em segundo plano? Isso é estável?

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

Integrei pipexeccom RHEL6 e não há problemas; ele simplesmente funciona.

Atenciosamente - Andreas

informação relacionada