upstart memcached
Последняя строка содержит две команды.
Первая часть устанавливает boot-repair. (sudo apt-get install -y boot-repair)
«& amp; & amp;» символы - это разделитель типа «;» однако, это обусловлено успехом, т. е. команда, следующая за ней, должна запускаться только в том случае, если первая команда не имела ошибок.
«Вторая» boot-repair - это ту, которая ее запускает.
2 ответа
Это хорошее начало, но есть несколько вещей, которые вы, возможно, неправильно поняли о выскочке здесь:
start on started
Начатое событие испускается каждый раз, когда любое задание на система запускается. Вероятно, вы должны были иметь что-то другое после начала, например start on started networking. К сожалению, это было бы неправильно, так как сетевое взаимодействие не так значимо, как подразумевалось в его названии. Для memcached он может в значительной степени работать в любое время после достижения уровня 2. Итак,
start on runlevel [2345]
Работает и необходимо, учитывая вашу остановку на правиле:
stop on runlevel [!2345]
Я знаю его немного запутанным, но на самом деле вам нужно использовать '^' вместо '!' здесь, так что вы хотите
stop on runlevel [^2345]
Также стоит отметить, что это остановится на уровне запуска 1, который является «режимом обслуживания одного пользователя». Но ваш первоначальный старт не начнет работать на уровне выполнения 2. Это будет ошибкой, поэтому убедитесь, что уровни выполнения соблюдены должным образом.
Ваш пост-стоп и exec игнорируют тот факт, что выскочка собирается попробуйте и отследите этот pid, но из-за того, что скрипт start-memcached завершает работу (поскольку он позволяет memcached daemonize), pid будет потерян. Это означает, что выскочка не может воспламениться, потому что она не знает о pid в первую очередь и не знает, что она умерла.
Если вы хотите, чтобы у вас появилась респауна, вы Вероятно, хотите:
expect daemon
exec $DAEMONBOOTSTRAP
В этом случае нет необходимости использовать start-stop-daemon. Upstart будет отслеживать pid, и когда вы «остановите memcached», он отправит ему SIGTERM. Также файл конфигурации memcached уже запускает memcached как пользователь, отличный от root (memcache) в Ubuntu 10.10 и более поздних версиях, поэтому вам, вероятно, также не нужно беспокоиться об изменении идентификатора пользователя.
Вот сценарий Upstart, который я использовал для memcached. Это сильно зависит от реакции SpamapS, но с ключом подстройки отказаться от использования start-memcached.
Использования start-memcached результатов в три технологических вилке для создания окончательного memcached процесса демона. Upstart, кажется, поддерживает только ноль через три вилки:
Ноль вилки, не имеющие expect п, один вилок с expect fork п, или две вилки с с expect daemon п.В ходе тестирования с использованием expect daemon с start-memcached обертки иногда в результате Upstart отслеживания неправильный идентификатор процесса, и в этот момент Upstart входит в разбитое состояние, в котором Upstart зависает при попытке запустить или остановить процесс. Обстановка Bummer, которую трудно исправить без перезагрузки. Обсуждение приводит к нулю до трех вилок имеет некоторые полезные советы по whatto делать, если это произойдет.
В результате я отошел от использования start-memcached обертки и просто inlined memcached в сценарии Upstart ниже. Поскольку процесс запускается непосредственно Upstart, нет необходимости в предложении expect. Несколько других заметок включены в строку.
description "memcached"
env MEMCACHED=/usr/bin/memcached
start on runlevel [2345]
# Not sure why it was recommended to use ^ rather than !. I'm sticking with !.
stop on runlevel [!2345]
# This test is completely optional, I'm just paranoid.
pre-start script
test -x $MEMCACHED || { stop; exit 0; }
end script
respawn
exec $MEMCACHED -m 384 -p 11211 -u memcache -l 127.0.0.1