Script inicial que depende dos scripts init.d?


8

Eu tenho um script inicial para iniciar um aplicativo nodejs personalizado. O aplicativo depende do couchdb e do elasticsearch. couchdb e elasticsearch fornecem scripts init.d para iniciá-los / pará-los. É possível dizer ao meu script inicial que couchdb e elasticsearch são dependências? Eu tentei isso no meu script inicial, mas ele não parece funcionar:

start on (iniciado couchdb e elasticsearch)

Obrigado!



Eu tentei o seguinte: start on iniciado rc RUNLEVEL = [2345] mas não ajuda. O Elasticsearch não foi iniciado quando meu aplicativo foi iniciado. Portanto, parece que não há como o meu script inicial saber se os serviços iniciados pelos scripts init já foram iniciados?
Troy

bem, a única coisa que sei que funcionaria é criar (ou procurar e instalar) scripts iniciados para elasticsearch e couchdb, para que você possa usar a opção "iniciar".
Rinzwind

Veja se esta resposta é útil! Encontrei um script inicial para ambos: D Código não testado, portanto, você pode precisar ajustá-lo para sua situação.
Rinzwind

Respostas:


3

A única coisa que sei que funcionaria é criar (ou procurar e instalar) scripts iniciados para elasticsearch e couchdb, para que você possa usar a opção "iniciar".

Script inicial para couchdb

# couchdb v1.2.0
#
# Instalação personalizada do CouchDB

descrição "CouchDB v1.2.0, local"
saída do console

# start depois que todos os sistemas de arquivos e interfaces de rede estiverem disponíveis
iniciar (sistemas de arquivos locais e IFACE! = lo)
parar no nível de execução [! 2345]

# definir diretório de trabalho
env COUCHDB_WD = "/ caminho / para / build-couchdb / build / bin"
exportar COUCHDB_WD

# necessário para erlang
env HOME = "/ home / usuário"
exportar HOME

roteiro
  # modify PATH para acessar o diretório de trabalho local do couchdb primeiro
  PATH = "$ COUCHDB_WD: $ PATH"
  #export PATH # não é necessário dentro do bloco de scripts
  #logger -t $ 0 "HOME = '$ HOME'"
  #logger -t $ 0 "PATH = '$ PATH'"
  # output logs do couchdb no local personalizado
  #exec >> / home / user / couchdb_local.log 2> & 1
  exec couchdb
script final

Upstart para elasticsearch

# ElasticSearch Service

descrição "ElasticSearch"

iniciar (net-device-up
          e sistemas de arquivos locais
          e nível de execução [2345])

parar no nível de execução [016]

limite de reaparecimento 10 5

env ES_HOME = / usr / share / elasticsearch / home
env ES_MIN_MEM = 256m
env ES_MAX_MEM = 2g
env DAEMON = "$ {ES_HOME} / bin / elasticsearch"
env DATA_DIR = / data / elasticsearch / data
env CONFIG_DIR = / etc / elasticsearch

saída do console

roteiro
  if [-f / etc / default / elasticsearch]; então
    . / etc / default / elasticsearch
  fi

  su -s / bin / dash -c "/ usr / bin / elasticsearch -f -Des.path.conf = $ CONFIG_DIR -Des.path.home = $ ES_HOME -Des.path.logs = $ LOG_DIR -Des.path. data = $ DATA_DIR -Des.path.work = $ WORK_DIR "pesquisa elástica
script final

Acabei criando apenas um script init.d. Obrigado pela sua ajuda.
Troy

Eu acho que você está correto ... Acabei de criar o script init.d por enquanto como um curativo devido a restrições de tempo.
Troy

Isso também funcionará, mas é uma regressão;) Desde que a 12.10 é favorável ao iniciante, esperava que o iniciante fosse a melhor opção. Mas se você tem que trabalhar com o init script de ir para ele;)
Rinzwind

7

Eu tinha a mesma pergunta e também encontrei uma resposta diferente . O autor lista 4 opções para fazer isso, das quais eu gosto mais da primeira:

Use initclt emit myservice-startedpara sinalizar a conclusão da inicialização do seu serviço dependente. Na resposta vinculada, sugere-se adicionar essa linha ao final do init.dscript do serviço de dependência , mas eu prefiro um método diferente. Eu gosto de criar um novo inid.dscript chamado myservice-startedque contém apenas uma startseção. Usando o estilo de comentário apropriado no cabeçalho do arquivo, declaro que ele depende $myservicepara ser iniciado. Na startseção, eu falo sobre myservicecomo começar. Você pode instalá-lo com update-rc.d.

Eu gosto desta solução porque não é intrusiva; se uma atualização alterar qualquer um dos init.dscripts existentes , não afetará esses scripts adicionais. Mas lembre-se de que são necessárias alterações nos scripts iniciais .

Pode ser assim:

#!/bin/sh -e

### BEGIN INIT INFO
# Provides:          myservice-started
# Required-Start:    $myservice
# Default-Start:     2 3 4 5
# Short-Description: send upstart signal after starting myservice
# Description:       myservice needs to run before some upstart services can run
### END INIT INFO

. /lib/lsb/init-functions

case "$1" in
    start)
        log_daemon_msg "Signaling myservice started..." "myservice-started"
        initctl emit myservice-started --no-wait
    ;;

    *)
        log_action_msg "Usage: /etc/init.d/myservice-started start"
        exit 1
    ;;
esac

exit 0

Seu script inicial que está aguardando o myservice pode ouvir o myservice-startedevento:

start on myservice-started
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.