¿Script de inicio que depende de los scripts init.d?

Tengo un script inicial para iniciar una aplicación de nodejs personalizada. La aplicación depende de couchdb y elasticsearch. couchdb y elasticsearch proporcionan scripts init.d para iniciarlos / detenerlos. ¿Es posible decirle a mi script de inicio que couchdb y elasticsearch son dependencias? Intenté esto en mi script de inicio, pero parece que no funciona:

iniciar en (inició couchdb y comenzó elasticsearch)

¡Gracias!

upstart

— Troya
fuente

askubuntu.com/questions/109516/… ;)

— Rinzwind

Intenté esto: iniciar en iniciado rc RUNLEVEL = [2345] pero no ayuda. Elasticsearch no se inició cuando comenzó mi aplicación. Entonces, ¿parece que mi script inicial no puede saber si los servicios iniciados por los scripts de inicio ya han comenzado?

— Troya el

bueno, lo único que sé que funcionaría es crear (o buscar e instalar) secuencias de comandos de inicio para elasticsearch y couchdb para que pueda usar la opción "iniciar".

— Rinzwind

¡Vea si esta respuesta es útil! Encontré un script inicial para ambos: D Código no probado, por lo que es posible que deba modificarlo para su situación.

— Rinzwind

Respuestas:

Lo único que sé que funcionaría es crear (o buscar e instalar) secuencias de comandos de inicio para elasticsearch y couchdb para que pueda usar la opción "iniciar".

Script de arranque para couchdb

# couchdb v1.2.0
# #
# Instalación personalizada de CouchDB

descripción "CouchDB v1.2.0, local"
salida de consola

# comienza después de que todos los sistemas de archivos y la interfaz de red estén disponibles
comenzar en (local-filesystems y net-device-up IFACE! = lo)
detenerse en el nivel de ejecución [! 2345]

# establecer directorio de trabajo
env COUCHDB_WD = "/ ruta / a / build-couchdb / build / bin"
exportar COUCHDB_WD

# requerido para erlang
env HOME = "/ inicio / usuario"
exportar INICIO

guión
  # Modificar RUTA para golpear primero el directorio de trabajo de couchdb local
  RUTA = "$ COUCHDB_WD: $ RUTA"
  #export PATH # no es necesario dentro del bloque de script
  #logger -t $ 0 "HOME = '$ HOME'"
  #logger -t $ 0 "PATH = '$ PATH'"
  # salida de registros de couchdb a una ubicación personalizada
  #exec >> / home / user / couchdb_local.log 2> & 1
  exec couchdb
fin de guión

edite el entorno a lo que necesita;
Fuente: /programming/11980900/how-to-get-custom-couchdb-to-run-as-upstart-job

Advenedizo para búsqueda elástica

# ElasticSearch Service

descripción "ElasticSearch"

comenzar en (net-device-up
          y sistemas de archivos locales
          y runlevel [2345])

detenerse en el nivel de ejecución [016]

límite de reaparición 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

salida de consola

guión
  if [-f / etc / default / elasticsearch]; entonces
    . / 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 "elasticsearch
fin de guión

Fuente: https://gist.github.com/rbscott/1052015
Cambie el directorio ambiental a lo que necesita.

— Rinzwind
fuente

Terminé creando un script init.d en su lugar. Gracias por tu ayuda sin embargo.

— Troy

Creo que tienes razón ... Acabo de crear el script init.d por ahora como una curita debido a limitaciones de tiempo.

— Troy

Eso también funcionará, pero es una regresión;) Dado que 12.10 favorece el arranque, esperaba que el arranque sea la mejor opción. Pero si lo tienes trabajando con el guión de inicio, adelante;)

— Rinzwind

Tenía la misma pregunta y también encontré una respuesta diferente . El autor enumera 4 opciones para lograr esto, de las cuales me gusta la primera mejor:

Utilícelo initclt emit myservice-startedpara indicar la finalización del inicio de su servicio dependiente. En la respuesta vinculada, se sugiere agregar esta línea al final del init.dscript del servicio de dependencia , pero prefiero un método diferente. Me gusta crear un nuevo inid.dscript llamado myservice-startedque solo contiene una startsección. Utilizando el estilo de comentario apropiado en el encabezado del archivo, declaro que depende de $myserviceque se inicie. En la startsección, le cuento al advenedizo acerca de myservicehaber comenzado. Puedes instalarlo con update-rc.d.

Me gusta esta solución porque no es intrusiva; Si una actualización cambia cualquiera de los init.dscripts existentes , no afectará estos scripts adicionales. Pero recuerde que se requieren cambios en sus secuencias de comandos iniciales .

Podría verse así:

#!/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

Su secuencia de comandos inicial que espera myservice puede escuchar el myservice-startedevento:

start on myservice-started

— derabbink
fuente