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

Я подозреваю, что ваша проблема может заключаться в том, что ваш 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, демонстрирующий это.

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

повторное выполнение разветвленного дочернего элемента... 53 exec': Нет такого файла или каталога - /var/www/application/releases/153565b36021c0b8c9cbab1cc373a9c5199073db/vendor/bundle/ruby/1.9.1/bin/unicorn (Errno::ENOENT)

В документах Unicorn эта потенциальная проблема упоминается по адресу http://unicorn.bogomips.org/Sandbox.html. : «очистка старых ревизий приведет к тому, что установки unicorn для конкретной ревизии пропадут, а обновления завершатся сбоем», что в моем случае означало, что 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"

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

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

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

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