Capistrano не перезапускает кластеры Mongrel правильно

Question

У меня есть кластер из трех mongrels, работающих под nginx, и я развертываю приложение, используя Capistrano 2.4.3. Когда я «закрываю развертывание», когда есть работающая система, это поведение:

1. Приложение развернуто. Код успешно обновлен.

2. В выходном колпачке развертывания, есть это:

   • выполнения «Суд -p 'Sudo пароль:' mongrel_rails кластер :: перезагружать -C /вар/WWW/Рельсы/MyApp/ток/конфиг/mongrel_cluster.yml»
   • серверов: [ "MyIP"]
   • [MyIP] выполнение команды
   • ** [из :: MyIP] останавливая порт 9096
   • ** [из :: MyIP] останавливая порт 9097
   • ** [из :: MyIP] останавливая порт 9098
   • ** [из :: MyIP] уже начал порт 9096
   • ** [из :: MyIP] уже начал порт 9097
   • ** [ out :: myip] уже начато порт 9098
3. Я проверяю немедленно на сервере и обнаруживаю, что Mongrel все еще работает, и файлы PID все еще присутствуют для предыдущих трех экземпляров.
4. Спустя короткое время (менее одной минуты) я обнаружил, что Mongrel больше не работает, файлы PID исчезли, и он не смог перезапустить.
5. Если я запускаю mongrel на сервере вручную, приложение запускается просто отлично.

Перед попыткой перезагрузки кластера кажется, что кластер mongrel_rails :: restart 'должным образом не ждет полной остановки . Как мне диагностировать и устранить эту проблему?

EDIT: Вот ответ:

mongrel_cluster, в задаче «перезагрузки», просто делает это:

def run 
    stop 
    start 
end 

Это не делает никакого ожидания или проверки, чтобы увидеть, что процесс вышел перед тем вызывая «начало». Это a known bug with an outstanding patch submitted. Я применил патч к кластеру Mongrel, и проблема исчезла.

Answer 1

Вы можете явно сказать mongrel_cluster рецептов для удаления Pid файлов перед началом, добавив следующую строку в вашем Capistrano рецептов:

# helps keep mongrel pid files clean 
set :mongrel_clean, true 

Это приводит к тому, что передать --clean возможности mongrel_cluster_ctl.

Я вернулся и посмотрел на один из моих рецептов развертывания и заметил, что я также изменил способ работы с перезагрузкой. Посмотрите на следующее сообщение в группе пользователей беспородных:

mongrel users discussion of restart

Следующая моя Deploy: перезапуск задачи. Я признаю, что это немного взломать.

namespace :deploy do 
    desc "Restart the Mongrel processes on the app server." 
    task :restart, :roles => :app do 
    mongrel.cluster.stop 
    sleep 2.5 
    mongrel.cluster.start 
    end 
end 

Answer 2

Ненавижу быть настолько основательным, но похоже, что файлы pid все еще висят вокруг, когда он пытается начать. Убедитесь, что дворняжка остановлена ​​вручную. Очистите файлы pid вручную. Затем разверните крышку.

Answer 3

Во-первых, сузите сферу вашего тестирования, позвонив только по телефону cap deploy:restart. Возможно, вы захотите передать опцию --debug, чтобы запросить перед удаленным исполнением или опцию --dry-run, чтобы увидеть, что происходит, когда вы настраиваете свои настройки.

На первый взгляд это звучит как проблема с разрешениями на файлы pid или mongrel-процессы, но это трудно понять наверняка.Пара вещей, которые бросаются в глаза, являются:

• переменная :runner явным образом устанавливается в nil - Была ли конкретная причина для этого?
• Capistrano 2.4 вводитповедение для переменной :admin_runner. Не видя весь рецепт, возможно, это связано с вашей проблемой?

  : бегун против: admin_runner (от capistrano 2.4 release) Некоторые Капперс отметили, что наличие развертывания: установки и развертывания: запуск очистки, как: бегун пользователь испортили свои тщательно разработанные разрешения. Я согласился, что это проблема. В этом выпуске развертывание: запуск, развертывание: остановка и развертывание: перезапустите все, чтобы продолжать использовать пользователя: runner, когда используется sudoing, но развертывание: установка и развертывание: cleanup будет использовать пользователя admin_runner. Переменная: admin_runner не установлена, по умолчанию означает, что эти задачи будут выполняться как root, но если вы хотите, чтобы они выполнялись как: runner, просто выполните «set: admin_runner, runner».

Моя рекомендация для того, что делать дальше. Вручную остановить ублюдок и очистить PID. Начать ругательств вручную. Затем продолжите выполнение cap deploy:restart при отладке проблемы. При необходимости повторите.

Answer 4

В любом случае, мои ублюдки начинаются до того, как команда предыдущей остановки завершила закрытие «все вниз».

Сон 2.5 не является хорошим решением, если требуется больше 2,5 секунд, чтобы остановить все запущенные мечты.

Там, как представляется, необходимо:

stop && start 

VS.

stop; start 

(это как Баш работает, & & ожидает первой команды до конца без ошибок, в то время как ";" просто запускает следующую команду).

Интересно, если есть:

wait cluster_stop 
then cluster_start 

Answer 5

Хорошее обсуждение: http://www.ruby-forum.com/topic/139734#745030