Единорог полностью игнорирует сигнал USR2

Question

У меня довольно странная проблема с единорогом на рабочем сервере. Хотя в файле конфигурации указано preload_app true, отправка USR2 в главный процесс не генерирует никакого ответа, и кажется, что единорог полностью игнорирует сигнал. На другом сервере отправка USR2 переводит главный процесс в и (старое) состояние и успешно запускает новый главный процесс. Проблемный сервер использует RVM & bundler, поэтому я предполагаю, что он каким-то образом связан (другой - vanilla ruby). Отправка сигналов кроме USR2 (QUIT, HUP) работает просто отлично. Есть ли способ отследить, что здесь происходит за кулисами? Файл журнала Unicorn полностью пуст.

Answer 1

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

Проверьте ваш /log/unicorn.log для получения подробной информации о том, что может быть неудачным.

Если вы используете Capistrano, укажите BUNDLE_GEMFILE в качестве символической ссылки, например ::

run "cd #{current_path} && BUNDLE_GEMFILE=#{current_path}/Gemfile bundle exec unicorn -c #{config_path} -E #{unicorn_env} -D"

Вот PR , который демонстрирует это.

Answer 2

Я столкнулся с подобной проблемой, но мои журналы четко идентифицировали проблему: отправка USR2 первоначально будет работать на развертываниях, но, как только развертывания будут очищены, выпуск, на котором изначально был запущен мастер Unicorn, будет удален, поэтому попытки отправкисигнал USR2, по-видимому, ничего не делает / терпит неудачу, с журналом ошибок, в котором указано:

раздвоенный дочерний процесс, выполняющийся повторно ... 53 / var / www / application / Releases / 153565b36021c0b8c9cbab1cc373a9c5199073db / vendor / bundle /ruby / 1.9.1 / gems / unicorn-4.3.1 / lib / unicorn / http_server.rb: 439: в `exec ': нет такого файла или каталога - / var / www / application / Releases / 153565b36021c0b8c9cbab1cc373a9c5199073db / vendor / bundle /ruby / 1.9.1 / bin / unicorn (Errno :: ENOENT)

В документах Unicorn упоминается эта потенциальная проблема при http://unicorn.bogomips.org/Sandbox.html: «очистка старых ревизий приведет к установке конкретных ревизийединорог пропадет, а обновления потерпят неудачу ", что в моем случае означало, что USR2" ничего не делает ".

Я использую приложение от Chefкатионный рецепт для развертывания приложений, который создает символическую директорию vendor_bundle, которая используется совместно для всех развертываний, но при вызове bundle exec unicorn исходный мастер Unicorn все еще содержал ссылку на путь, которая включала конкретный каталог выпуска.

Чтобы исправить этоМне пришлось позвонить bundle exec /var/www/application/shared/vendor_bundle/ruby/1.9.1/bin/unicorn, чтобы убедиться, что мастер Unicorn имеет путь к двоичному файлу, который будет действителен от одного развертывания к другому.Как только это будет сделано, я смогу развернуть для себя все необходимое, и kill -USR2 PID будет работать так, как объявлено.

В документации Unicorn упоминается, что вы можете вручную изменить ссылку на двоичный путь, установив следующее в файле конфигурации Unicorn и отправивHUP для перезагрузки Unicorn перед отправкой USR2 для разветвления нового мастера: Unicorn::HttpServer::START_CTX[0] = "/some/path/to/bin/unicorn"

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

Answer 3

Я столкнулся с похожей проблемой на моем VDS.Strace'ing выявил причину:

write(2, "E, [2011-07-23T04:40:27.240227 #19450] ERROR -- : Cannot allocate memory - fork(2) (Errno::ENOMEM) <...>

Попробуйте увеличить объем памяти, ограничения памяти XEN по требованию (в моем случае они были слишком жесткими) или, возможно, включить overcommit черезпоследний может иметь некоторые серьезные нежелательные побочные эффекты, поэтому делайте это осторожно.