Impossible de démarrer la console rails 4 sur le serveur de production

Avoir un problème bizarre et besoin d'aide.

J'essaie de démarrer une console rails sur un serveur de production et il agit comme si la commande rails c n'existait pas.

FWIW, je suis un développeur rails depuis 4 ans et je le fais tout le temps sur une pléthore d'autres serveurs sans problème. Sur ce serveur, je peux déposer, créer, migrer, semer la base de données sans problème (en utilisant RAILS_ENV = production), et l'application fonctionne bien en direct sans aucun problème.

Configuration:

Ubuntu 14.04 (serveur racksapce 2nd gen performance 1)
Nginx avec Passenger (j'utilise généralement Unicorn, mais je n'ai jamais eu de problème sur aucune des applications que j'ai déployées avec Passenger)
Ruby 2.1.5 (en utilisant rvm)
Rails 4.1.7
Postgres
Capistrano 3 (Utilisation du rvm, migrations, précompilation d'actifs, etc. extensions)

Ce que j'ai essayé:

Cd dans le répertoire de l'application:

cd /home/deployer/app_name/current

Qui se charge .rvmrc et spectacles que je suis dans le gemset correct, a couru bundle juste pour les coups de pied.

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

Chaque fois, je reçois un avis qui implique que 'rails c' n'est pas une commande valide:

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?)

Encore une fois, je me suis connecté à des centaines de consoles de production sur nginx/apache déployées avec les anciennes et nouvelles versions de Unicorn et surtout les anciennes versions de Passenger.

C'est la première fois que je reçois ce message, et la console est la seule chose qui semble être cassée - tout le reste fonctionne bien! le app est en direct et fonctionne très bien.

Je sais que la première chose à Suggérer est que je n'exécute pas la production de rails C à partir du répertoire de l'application - j'ai cd'D dans le répertoire correct au moins 10 fois et chargé manuellement le gemset correct, ce n'est pas le problème.

Ne peut pas comprendre pourquoi cela fonctionne bien dans le développement, mais pas dans la production. Je sais qu'il y avait un répertoire de scripts il y a quelque temps (peut-être rails 2?)- Est-il encore un répertoire qui contient les commandes de script pour rails qui peuvent avoir été corrompus?

Quelqu'un A déjà connu cela avant, ou avez des suggestions?

J'ai l'impression de manquer quelque chose.

36
demandé sur Pimgd 2015-01-30 22:14:50

2 réponses

Ok, trouvé le problème... @stoodfarback était assez proche, mais je pensais que la cause du problème devait être mentionnée pour d'autres qui pourraient rencontrer la même chose.

Fondamentalement, j'utilise une version plus récente de Capistrano (3.3.5) que je l'ai utilisé dans le passé et il (par défaut) ajoute 'bin' à la liste des répertoires partagés qu'il lie symboliquement sur chaque déploiement.

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

Le script deploy a donc créé un nouveau répertoire dans shared appelé bin (qui était vide) et les fichiers utilisés pour lancer rails serveur et console étaient manquants. Ils étaient évidemment toujours là en développement, Donc cela n'a affecté que la production.

Supprimé ' bin ' de la liste linked_dirs et tout fonctionne maintenant comme prévu.

Ressemble Maintenant à:

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

J'ai remarqué sur les dernières versions de Capistrano que j'ai utilisées, le format et les valeurs par défaut de linked_dirs changent un peu, mais je n'avais jamais vu bin dans cette liste. Je ne sais pas vraiment pourquoi bin aurait besoin d'être symlinked... il a seulement les fichiers rails par défaut et je ne peux pas penser à pourquoi ils auraient besoin d'être supprimés du contrôle de source, mais peut-être que L'équipe Capistrano a une raison.

J'espère que cela aide quelqu'un.

65
répondu johndavid400 2015-02-04 15:08:37

Vérifiez si vous avez l'un de ces fichiers et essayez de les supprimer:

  • script/rails
  • bin/rails
2
répondu stoodfarback 2015-01-31 04:58:26