выскочка memcached
Я собрал скрипт upstart для memcached на основе скрипта init.d, с которым он поставляется, поскольку нигде не смог найти ни одного примера. Проблема в том, что он не появляется автоматически, когда я убиваю процесс.
env DAEMON=/usr/bin/memcached
env DAEMONBOOTSTRAP=/usr/share/memcached/scripts/start-memcached
start on started
stop on runlevel [!2345]
respawn
post-stop script
start-stop-daemon --stop --pidfile /var/run/memcached.pid --name memcached --chuid nobody --user nobody --exec $DAEMON --signal TERM
end script
exec start-stop-daemon --start --quiet --exec $DAEMONBOOTSTRAP
2 ответа
Это хорошее начало, но есть несколько вещей, которые вы, возможно, неправильно поняли о выскочке здесь:
start on started
Запущенное событие генерируется каждый раз любой [ 116] работа в системе запущена. Вы, вероятно, хотели иметь что-то еще после начала, например start on started networking. К сожалению, это было бы неправильно, так как сетевое взаимодействие на самом деле не так значимо, как предполагает его название. Для memcached он может работать в любое время после достижения уровня запуска 2. Итак,
start on runlevel [2345]
Работает, и это необходимо, учитывая вашу остановку на правиле:
stop on runlevel [!2345]
Я знаю, это немного сбивает с толку, но вы на самом деле должны использовать «^» вместо «!» здесь, так что вы хотите
stop on runlevel [^2345]
Также стоит отметить, что это остановится на уровне выполнения 1, который является «режимом обслуживания одного пользователя». Но ваш первоначальный запуск не запустится обратно на уровне выполнения 2. Это будет ошибкой, поэтому убедитесь, что уровни запуска соблюдаются должным образом.
Ваши post-stop и exec игнорируют тот факт, что upstart попытается отследить этот pid, но поскольку скрипт start-memcached завершается (потому что он позволяет memcached демонизировать себя), pid будет потерян. Это означает, что выскочка не может возродиться, потому что она вообще не знает о pid и не знает, что он умер.
Если вы хотите иметь возможность его повторного вызова, вы, вероятно, захотите:
expect daemon
exec $DAEMONBOOTSTRAP
В этом случае нет необходимости использовать start-stop-daemon. Upstart будет отслеживать pid, и когда вы сделаете «stop 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 зависает при попытке запустить или остановить процесс. Облом ситуации, которую трудно исправить без перезагрузки. Обсуждение, ведущее к комментарию № 47, здесь, , дает несколько полезных советов о том, что делать, если это произойдет.
В результате я отошел от использования оболочки start-memcached и просто вставил конфигурацию 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