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

Question

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

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

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

Установка:

Ubuntu 14,04 (racksapce второй характеристики генераторных 1 сервер)
Nginx с пассажиром (я обычно использую Unicorn, но никогда не было проблем ни по одному из приложений, которые я раскрывали с пассажиром)
Рубин 2.1.5 (с помощью РВМ)
Рельсы 4.1.7
Postgres
Capistrano 3 (с использованием RVM, миграции, активов-прекомпиляцию и т.д.) Расширения

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

кд в папку приложения:

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 

Каждый раз, когда я получаю уведомление, что подразумевает «рельсы с» не является допустимой командой:

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/апаче, развернутые с старые и новые версии как Unicorn, так и, в основном, более старых версий Passenger.

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

• script/rails
• bin/rails