Upstart скрипт, который зависит от скриптов init.d?

У меня есть сценарий upstart для запуска пользовательского приложения nodejs. Приложение зависит от couchdb иasticsearch. couchdb иasticsearch предоставляют сценарии init.d для их запуска / остановки. Можно ли сказать моему сценарию выскочки, что couchdb иasticsearch являются зависимостями? Я пробовал это в моем сценарии выскочки, но это не похоже на работу:

начать (запустил couchdb и запустил эластичный поиск)

Спасибо!

upstart

— Трой
источник

askubuntu.com/questions/109516/… ;)

— Rinzwind,

Я попробовал это: начать с запуска rc RUNLEVEL = [2345], но это не помогает. Elasticsearch не был запущен, когда мое приложение запустилось. Таким образом, кажется, у моего сценария выскочки нет способа узнать, запущены ли уже службы, запущенные сценариями инициализации?

— Троя

ну, единственное, что я знаю, что это сработает, - это создание (или поиск и установка) сценариев выгрузки для обоих наборов упругого поиска и couchdb, чтобы вы могли использовать опцию «начать с».

— Rinzwind

Посмотрите, поможет ли этот ответ! Я нашел сценарий выскочки для обоих: D Неопробованный код, поэтому вам может потребоваться настроить его для вашей ситуации.

— Rinzwind

Ответы:

Единственное, что я знаю, что это сработает, - это создание (или поиск и установка) сценариев выгрузки для обоих наборов упругого поиска и couchdb, чтобы вы могли использовать опцию «начать с».

Upstart скрипт для couchdb

# couchdb v1.2.0
#
# Выборочная установка CouchDB

описание "CouchDB v1.2.0, local"
консольный вывод

# запуск после того, как все файловые системы и сетевое взаимодействие доступны
начать (локальные файловые системы и сетевое устройство IFACE! = lo)
остановитесь на уровне выполнения [! 2345]

# установить рабочий каталог
env COUCHDB_WD = "/ path / to / build-couchdb / build / bin"
экспорт COUCHDB_WD

# требуется для erlang
env HOME = "/ home / user"
экспорт ГЛАВНАЯ

скрипт
  # изменить PATH, чтобы сначала попасть в рабочий каталог локального couchdb
  PATH = "$ COUCHDB_WD: $ PATH"
  #export PATH # не обязательно внутри блока скрипта
  #logger -t $ 0 "HOME = '$ HOME'"
  #logger -t $ 0 "PATH = '$ PATH'"
  # вывод логов couchdb в произвольное местоположение
  #exec >> / home / user / couchdb_local.log 2> & 1
  exec couchdb
конец сценария

отредактируйте env так, как вам нужно;
Источник: /programming/11980900/how-to-get-custom-couchdb-to-run-as-upstart-job

Выскочка для эластичного поиска

# ElasticSearch Service

описание "ElasticSearch"

начать с (net-device-up
          и локальные файловые системы
          и уровень запуска [2345])

остановка на уровне выполнения [016]

предел возрождения 10 5

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

консольный вывод

скрипт
  if [-f / etc / default /asticsearch]; тогда
    , / И т.д. / по умолчанию / elasticsearch
  фи

  su -s / bin / dash -c "/ usr / bin /asticsearch -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 "эластичный поиск
конец сценария

Источник: https://gist.github.com/rbscott/1052015
Измените env dir на то, что вам нужно.

— Rinzwind
источник

В итоге я просто создал скрипт init.d. Спасибо за вашу помощь, хотя.

— Троя

Я думаю, что вы правы ... Я только что создал сценарий init.d в качестве лейкопластыря из-за нехватки времени.

— Троя

Это тоже будет работать, но это регресс;) Так как 12.10 благоприятствует выскочке, я ожидал, что выскочка будет лучшим вариантом. Но если у вас есть работа со сценарием инициализации,

— сделайте

У меня был тот же вопрос, и я также нашел другой ответ . Автор перечисляет 4 варианта для достижения этой цели, из которых мне больше всего нравится первый:

Используйте, initclt emit myservice-startedчтобы сообщить о завершении запуска вашей зависимой службы. В связанном ответе предлагается добавить эту строку в конец init.dскрипта службы зависимостей , но я предпочитаю другой метод. Мне нравится создавать новый inid.dскрипт с именем, myservice-startedкоторый содержит только startраздел. Используя соответствующий стиль комментирования в заголовке файла, я заявляю, что это зависит от $myserviceзапуска. В startразделе я расскажу выскочку о myserviceтом, как начать. Вы можете установить его с помощью update-rc.d.

Мне нравится это решение, потому что оно не навязчиво; если обновление изменяет какой-либо из существующих init.dсценариев, это не повлияет на эти дополнительные сценарии. Но помните , что изменения в ваших новомодных скрипты будут необходимы.

Это может выглядеть так:

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

Ваш сценарий upstart, ожидающий myservice, может прослушать myservice-startedсобытие:

start on myservice-started

— derabbink
источник