Skrypt upstart, który zależy od skryptów init.d?


8

Mam skrypt umożliwiający uruchomienie niestandardowej aplikacji nodejs. Aplikacja zależy od couchdb i elasticsearch. couchdb i elasticsearch zapewniają skrypty init.d do ich uruchamiania / zatrzymywania. Czy można powiedzieć mojemu skryptowi, że couchdb i elasticsearch są zależnościami? Próbowałem tego w moim skrypcie upstart, ale wydaje się, że to nie działa:

start on (rozpoczął couchdb i rozpoczął elasticsearch)

Dzięki!



Próbowałem tego: zacznij od uruchomionego rc RUNLEVEL = [2345], ale to nie pomaga. Funkcja Elasticsearch nie została uruchomiona podczas uruchamiania mojej aplikacji. Wygląda więc na to, że mój skrypt startowy nie ma sposobu, aby dowiedzieć się, czy usługi uruchomione przez skrypty init już się uruchomiły?
Troy

cóż, jedyne, co wiem, co by działało, to tworzenie (lub wyszukiwanie i instalowanie) skryptów upstart zarówno dla elasticsearch, jak i couchdb, aby można było użyć opcji „start on”.
Rinzwind

Sprawdź, czy ta odpowiedź jest pomocna! Znalazłem skrypt wstępny dla obu: D Nieprzetestowany kod, więc być może będziesz musiał go dostosować do swojej sytuacji.
Rinzwind

Odpowiedzi:


3

Jedyne, co wiem, co by działało, to tworzenie (lub wyszukiwanie i instalowanie) skryptów wstępnych dla zarówno elasticsearch, jak i couchdb, aby można było użyć opcji „start on”.

Skrypt upstart dla couchdb

# couchdb v1.2.0
#
# Niestandardowa instalacja CouchDB

opis „CouchDB v1.2.0, lokalny”
wyjście konsoli

# start po udostępnieniu wszystkich systemów plików i interfejsów sieciowych
start na (lokalne systemy plików i net-device-up IFACE! = lo)
stop na poziomie pracy [! 2345]

# ustaw katalog roboczy
env COUCHDB_WD = "/ path / to / build-couchdb / build / bin"
eksportuj COUCHDB_WD

# wymagane do erlang
env HOME = "/ home / user"
eksportuj HOME

scenariusz
  # zmodyfikuj ŚCIEŻKĘ, aby najpierw trafić do katalogu roboczego lokalnego couchdb
  PATH = "$ COUCHDB_WD: $ PATH"
  #export PATH # nie jest konieczne w bloku skryptu
  #logger -t $ 0 "HOME = '$ HOME'"
  #logger -t $ 0 "PATH = '$ PATH'"
  # wyjściowe dzienniki couchdb do niestandardowej lokalizacji
  #exec >> / home / user / couchdb_local.log 2> i 1
  exec couchdb
koniec skryptu

Upstart dla elasticsearch

# Usługa ElasticSearch

opis „ElasticSearch”

rozpocznij na (net-device-up
          i lokalne systemy plików
          i poziom pracy [2345])

zatrzymaj na poziomie pracy [016]

limit odrodzenia 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

wyjście konsoli

scenariusz
  if [-f / etc / default / elasticsearch]; następnie
    . / 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 "wyszukiwanie elastyczne
koniec skryptu

Zamiast tego po prostu stworzyłem skrypt init.d. Dziękuję za pomoc.
Troy

Myślę, że masz rację ... Właśnie utworzyłem na razie skrypt init.d jako pomoc dla zespołu z powodu ograniczeń czasowych.
Troy

To też zadziała, ale to regresja;) Od 12.10 faworyzuje upstart, spodziewałem się, że upstart będzie lepszą opcją. Ale jeśli masz go działającego ze skryptem init, idź na niego;)
Rinzwind 12.04.13

7

Miałem to samo pytanie i znalazłem inną odpowiedź . Autor wymienia 4 opcje, aby to osiągnąć, z których najbardziej podoba mi się ta pierwsza:

Służy initclt emit myservice-starteddo sygnalizowania zakończenia uruchamiania usługi zależnej. W połączonej odpowiedzi sugeruje się dodanie tego wiersza na końcu init.dskryptu usługi zależności , ale wolę inną metodę. Lubię tworzyć nowy inid.dskrypt o nazwie, myservice-startedktóry zawiera tylko startsekcję. Używając odpowiedniego stylu komentowania w nagłówku pliku, deklaruję, że zależy to od $myserviceuruchomienia. W tej startsekcji mówię na początku o myservicerozpoczęciu. Możesz go zainstalować za pomocą update-rc.d.

Podoba mi się to rozwiązanie, ponieważ nie jest nachalne; jeśli aktualizacja zmieni którykolwiek z istniejących init.dskryptów, nie wpłynie to na te dodatkowe skrypty. Pamiętaj jednak, że wymagane zmiany w skryptach upstart .

Może to wyglądać tak:

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

Twój skrypt startowy czekający na myservice może nasłuchiwać myservice-startedzdarzenia:

start on myservice-started
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.