Mina: проблемы с перезапуском puma

Созданный на 25 окт. 2014  ·  10Комментарии  ·  Источник: mina-deploy/mina

Очень часто после развертывания у меня остается неработающее веб-приложение ...

пума как-то умирает ...

-----> DB schema unchanged; skipping DB migration        
-----> Skipping asset precompilation        
-----> Cleaning up old releases (keeping 5)        
-----> Build finished        
-----> Moving build to releases/42        
-----> Updating the current symlink        
-----> Launching        
       Command phased-restart sent success 
-----> Done. Deployed v42        
       Elapsed time: 3.00 seconds

(здесь сайт не работает)

david<strong i="10">@eclipse</strong>:~/Projects/meetcasts (master)$ mina puma:restart
-----> Loading rbenv
Puma is not running!
[23126] Puma starting in cluster mode...
[23126] * Version 2.9.0 (ruby 2.1.2-p95), codename: Team High Five
[23126] * Min threads: 1, max threads: 16
[23126] * Environment: production
[23126] * Process workers: 2
[23126] * Preloading application
[23126] * Listening on unix:///var/www/meetcasts/shared/tmp/sockets/puma.sock
[23126] * Listening on tcp://0.0.0.0:3003
[23126] * Daemonizing...
Connection to example.com closed.
       Elapsed time: 4.00 seconds

(обратите внимание, что линия Puma не работает )

Иногда мне приходится повторять mina puma:restart несколько раз, чтобы заставить его работать ...

Это проблема пума? У меня есть несколько приложений sinatra, и когда я отправляю SIGUSR2, он всегда правильно перезагружается ... Может быть, в Rails есть проблемы, и это не проблема mina? Как я могу получить больше отладочных данных по этому поводу?

Самый полезный комментарий

Это проблема пумы. Проблема в том, что puma на самом деле не запускает демон сразу после запуска. Система убивает процесс puma при закрытии сеанса ssh. Вы можете исправить это, добавив sleep 1 после запуска puma.

Например:

namespace :puma do
  task :custom_start => :environment do
    command %[
      if [ -e '#{fetch(:pumactl_socket)}' ]; then
        echo 'Puma is already running!';
      else
        if [ -e '#{fetch(:puma_config)}' ]; then
          cd '#{fetch(:current_path)}' && #{fetch(:puma_cmd)} -d -e #{fetch(:puma_env)} -C #{fetch(:puma_config)}
          sleep 1
        else
          echo 'Puma config is required'
          exit 1
        fi
      fi
    ]
  end
end

Все 10 Комментарий

Итак, вы говорите, что при развертывании с использованием mina оно не запускается, но, как я вижу, когда вы отправляете ssh на свой сервер и запускаете mina puma: restart все в порядке? Не могли бы вы скопировать файл deploy.rb (только задачу развертывания) и запустить развертывание с параметром -v (mina deploy -v), а также написать мне ответ.

На самом деле я запускаю mina puma:restart локально (так что я не использую ssh, но mina использует), вы, вероятно, это заметили.

Я должен запускать это многократно, пока он внезапно не сработает (страница загрузится). Итак, снова после обычного развертывания сайт не загружается, а после запуска mina puma:restart он сообщает, что puma не запущена и запускает его сейчас. Затем иногда страница загружается, но часто мне приходится повторять от 5 до 7 раз, прежде чем это сработает.

Вот файл развертывания для одного проекта:
https://gist.github.com/davidhq/fe0decad29bb005e9a6d

Я думал, что на самом деле это происходит только в этом проекте, но сейчас это произошло в другом.

Я изучил код перезапуска puma

cd #{deploy_to}/#{current_path} && #{pumactl_cmd} -S #{puma_state} phased-restart

и вроде нормально .. но именно здесь все ломается в первую очередь ..

Я не знаю, как продолжить поиск неисправности, но похоже, что это проблема Puma, не так ли?

теперь у меня есть веб-приложение в неработающем состоянии после развертывания:

david<strong i="6">@theta</strong>:/var/www/tb/shared/tmp/sockets$ cat puma.state 
---
pid: 30362
config: !ruby/object:Puma::Configuration
  options:
    :min_threads: 1
    :max_threads: 16
    :quiet: true
    :debug: false
    :binds:
    - unix:///var/www/tb/shared/tmp/sockets/puma.sock
    - tcp://0.0.0.0:3007
    :workers: 1
    :daemon: true
    :worker_directory: "/var/www/tb/current"
    :environment: production
    :state: "/var/www/tb/shared/tmp/sockets/puma.state"
    :control_url: unix:///var/www/tb/shared/tmp/sockets/pumactl.sock
    :config_file: config/puma.rb
    :mode: :http
    :worker_timeout: 60
    :preload_app: true
    :rackup: config.ru
    :control_auth_token: 7d18137e9e5e7ea13dc2d3758397e3a
david<strong i="7">@theta</strong>:/var/www/tb/shared/tmp/sockets$ ps aux | grep 30362
[no process with such PID]

Может быть, это как-то связано с rsync, который я использую? Поскольку у моих друзей, которые развертывают с помощью mina, нет никаких проблем, но они не используют метод rsync ... Я думал, что, поскольку я не исключал / tmp (как, вероятно, должен) при rsyncing, это получило на сервере (и там есть сокет и состояние puma) .. но я не знаю, как это могло быть на пути, потому что символическая ссылка на / shared / tmp работает, и это происходит до перезапуска puma.

Не потому, что сегодня это случилось снова, и эти каталоги были исключены ... Я также обновил puma с 2.9.0 до 2.9.2 ... это немного расстраивает :( Могу ли я спросить у Puma?

Теперь я попытался заменить invoke :'puma:phased_restart' на:

queue "kill -SIGUSR2 `ps aux | grep tcp://0.0.0.0:3003 | grep puma | awk '{ print $2 }'`"

И это случилось снова при 3-м развертывании ... так что, похоже, это не проблема мины в любом случае ...

У меня есть новая информация .... https://github.com/puma/puma/issues/598 ... все еще не уверен, в чем проблема, но, по-видимому, puma отклоняет поэтапный перезапуск и после обычного перезапуска не может найти Gemfile для некоторая причина...

Оказывается, вы не можете использовать поэтапный перезапуск с предварительной загрузкой приложения ... Я надеюсь, что теперь все будет в порядке и это поможет другим ... подробнее об этом: https://github.com/puma/puma/blob/master/DEPLOYMENT .md # перезапуск

Кажется, что последняя ссылка возвращает 404, другие ссылки:
https://github.com/puma/puma/blob/master/docs/restart.md
https://github.com/puma/puma/blob/master/docs/deployment.md#restarting

Это проблема пумы. Проблема в том, что puma на самом деле не запускает демон сразу после запуска. Система убивает процесс puma при закрытии сеанса ssh. Вы можете исправить это, добавив sleep 1 после запуска puma.

Например:

namespace :puma do
  task :custom_start => :environment do
    command %[
      if [ -e '#{fetch(:pumactl_socket)}' ]; then
        echo 'Puma is already running!';
      else
        if [ -e '#{fetch(:puma_config)}' ]; then
          cd '#{fetch(:current_path)}' && #{fetch(:puma_cmd)} -d -e #{fetch(:puma_env)} -C #{fetch(:puma_config)}
          sleep 1
        else
          echo 'Puma config is required'
          exit 1
        fi
      fi
    ]
  end
end
Была ли эта страница полезной?
0 / 5 - 0 рейтинги