Подтвердить что ты не робот

Не удается запустить консоль рельсов 4 на сервере производства

Имеет странную проблему и нужна помощь.

Я пытаюсь запустить консоль рельсов на производственном сервере и действует как команда rails c не существует.

FWIW, я был разработчиком рельсов в течение 4 лет и делал это все время на множестве других серверов без проблем. На этом сервере я могу сбрасывать, создавать, переносить, сеять базу данных без проблем (используя RAILS_ENV = production), и приложение прекрасно работает без каких-либо проблем.

Настройка:

Ubuntu 14.04 (racksapce 2nd gen performance 1 server)
Nginx с пассажиром (я обычно использую Unicorn, но никогда не сталкивался с проблемой ни в одном из приложений, которые я развернул с помощью Passenger)
Ruby 2.1.5 (с использованием rvm)
Rails 4.1.7
Postgres
Capistrano 3 (использование rvm, миграций, предварительная компиляция активов и т.д.)

Что я пробовал:

cd в каталог приложения:

cd /home/deployer/app_name/current

Что загружает .rvmrc и показывает, что я нахожусь в правильном gemset, запускал пакет только для пинков.

rails c production # (which usually works no problem)

bundle exec rails c production # (sometimes have to do this on older apps that do not have the newer capistrano 3 and rvm setup)

rails c production RAILS_ENV=production # (getting desperate here)

RAILS_ENV=production rails c production # (haha, surely this won't work, but out of options)

RAILS_ENV=production bundle exec rails console

Каждый раз я получаю уведомление о том, что "rails c" не является допустимой командой:

Usage:
  rails new APP_PATH [options]

Options:
  -r, [--ruby=PATH]                                      # Path to the Ruby binary     of your choice

..... yada yada, shows the rest of the rails options (oddly enough does not show 'c' or 'console' as options?)

Опять же, я вошел в сотни консолей производства на nginx/apache, развернутых со старыми и новыми версиями как Unicorn, так и, в основном, более старых версий Passenger.

Это первый раз, когда я когда-либо получал это сообщение, а консоль - это ТОЛЬКО вещь, которая, кажется, сломана - все остальное отлично работает! приложение работает вживую и отлично работает.

Я знаю, что первое, что нужно предложить, это то, что я не запускаю рельсы c из каталога приложений. У меня есть cd'd в правильный каталог не менее 10 раз и вручную загружается правильный гемсет, это не проблема.

Не могу понять, почему он отлично работает в разработке, но не в производстве. Я знаю, что раньше был каталог скриптов (возможно, рельсы 2?). Есть ли еще каталог, содержащий команды script для рельсов, которые могли быть повреждены?

Кто-нибудь когда-либо испытывал это раньше или имел какие-либо предложения?

Я чувствую, что что-то не хватает.

4b9b3361

Ответ 1

Хорошо, нашел проблему... @stoodfarback был довольно близок, но я думал, что причина проблемы должна быть упомянута для других, которые могут столкнуться с тем же.

В основном я использую более новую версию Capistrano (3.3.5), чем я использовал в прошлом, и она (по умолчанию) добавляет "bin" в список общих каталогов, которые она символизирует при каждом развертывании.

set :linked_dirs, fetch(:linked_dirs, []).push('bin', 'log', 'tmp', 'public/system', "public/downloads", "public/assets")

Таким образом, развертывание script создало новый каталог в совместно используемом ящике bin (который был пуст), и файлы, используемые для запуска сервера и консоли рельсов, отсутствовали. Очевидно, они все еще были в разработке, поэтому это повлияло только на производство.

Удалено "bin" из списка связанных_dirs, и теперь все работает так, как ожидалось.

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

set :linked_dirs, fetch(:linked_dirs, []).push('log', 'tmp', 'public/system', "public/downloads","publ ic/assets")

Я заметил в последних версиях Capistrano, которые я использовал, формат и значения по умолчанию для linked_dirs постоянно меняются, но я никогда не видел bin в этом списке. Не совсем уверен, почему bin должен быть символически привязан... у него есть только файлы с рельсами по умолчанию, и я не могу придумать, почему их нужно будет удалить из исходного контроля, но, возможно, у команды Capistrano есть причина.

Надеюсь, это поможет кому-то.

Ответ 2

Проверьте, есть ли у вас какие-либо из этих файлов и попробуйте удалить их:

  • script/rails
  • bin/rails