Upstart: Qual é o primeiro PID rastreado sem esperar, mas com script AND exec?

Question

Eu tenho algumas configurações do Upstart usadas para iniciar alguns processos de primeiro plano e de bloqueio para serem executados em segundo plano como algum tipo de "daemons", especialmente aqueles processos não bifurcam em nenhum caso. O que eu quero é reiniciá-los automaticamente se eles saírem por qualquer motivo desconhecido, então eu configurei respawn , mas como esses processos não são compatíveis, eu NÃO configurei expect . Isso pareceu funcionar como esperado, mas recentemente eu mudei algo e hoje encontrei algo no livro de receitas Upstart novamente que me fez maravilha ...

If you do not specify the expect stanza, Upstart will track the life cycle of the first PID that it executes in the exec or script stanzas.

Eu uso uma sub-rotina script para criar o classpath para o meu "daemon" e recentemente adicionei alguns esperando que o Postgres e / ou alguns aplicativos da web fiquem prontos e executem o meu processo usando exec nesse script estrofe. Por esperar eu uso ferramentas como ps e curl , porque eu esqueci do "primeiro PID" e parece ter confundido o Upstarts exec com o do shell executando o script .

Um exemplo de configuração:

script
  waitForPostgres()
  {
    while [ true ]
    do
      # http://superuser.com/questions/597549/grep-fails-in-upstart-script
      if ps ax | grep "[p]ostgres: wal writer process" > /dev/null
      then
        break
      fi

      sleep 10s
    done
  }

  waitForPostgres

  cd "$basePath"

  CLASSPATH=$basePath/lib
  for i in 'ls $basePath/lib/*.jar'
  do
    CLASSPATH=$CLASSPATH:$i
  done
  export CLASSPATH

  exec java [...]
end script

O material waitForPostgres é novo e, do meu ponto de vista, todo o resto são internos do shell e sem waitForPostgres o primeiro processo executado e, portanto, controlado deve ser java . Mas com a minha função adicional eu suspeito que o Upstart rastreia ps e que obviamente não seria o que eu queria.

Então, qual PID é rastreado neste exemplo, de ps , grep ou java e por quê?

E se java não for rastreado, alguma idéia de soluções alternativas para rastrear o último PID em vez do primeiro?

Obrigado!

    

Answer 1

Eu encontrei a resposta usando alguns termos de pesquisa ligeiramente diferentes: expect stop

Unfortunately, this means Upstart detects the first invocation of sed as the first PID

Além disso, a resposta para uma solução alternativa está próxima, pre-start , que é exatamente projetada para essa finalidade. Não pensei sobre isso, mesmo que eu tenha lido antes nos documentos ...

Eu também encontrei uma proposta interessante: Possibilidade de dizer explicitamente que PID rastrear

Devido a alguns problemas com um dos meus serviços, tive outra visão de como ele se comporta com o Upstart e encontrei o seguinte: Minha sub-rotina "script" ainda está chamando binários como "dirname", "readlink" e "ls" para não precisa codificar um diretório de trabalho, construir algum caminho de classe Java e tal. A parte importante é que esses não são internos do shell e, portanto, devem ser rastreados pelo Upstart, porque "readlink" é o primeiro binário executado em "start". Mas esse não é o caso, esses PIDs parecem ser ignorados e o Upstart, em vez disso, rastreia o PID do comando "exec java ..." que eu realmente quero ver rastreado. Eu verifiquei isso chamando "serviço ... status" e comparando a saída com "ps axf | grep ..." e ambos os PIDs correspondem. Eu posso reiniciar corretamente o serviço e o PID encontrado anteriormente é removido e iniciar o serviço e o status ps e service ... reportam o mesmo PID novamente.

Duas explicações possíveis: Como "dirname" e Co. são usados como substituição de comando, o Upstart reconhece os subshells criados pelo próprio shell criado para a sub-rotina "script" e ignora esses PIDs por finalidade. Outro "exec" pode retornar um PID que substitui qualquer PID reconhecido anterior. Eu duvido do último e acho que sub-conjuntos são simplesmente ignorados, o que é uma característica muito legal então.