ruby on rails - pagina - No se puede iniciar la consola Rails 4 en el servidor de producción

ruby download for windows

Question

Tener un problema extraño y necesitar ayuda.

Estoy intentando iniciar una consola de rieles en un servidor de producción y está actuando como si el comando rails c no existiera.

FWIW, he sido desarrollador de rieles durante 4 años y lo hago todo el tiempo en una plétora de otros servidores sin problemas. En este servidor, puedo soltar, crear, migrar, sembrar la base de datos sin problemas (usando RAILS_ENV = producción), y la aplicación funciona bien en vivo sin ningún problema.

Preparar:

Ubuntu 14.04 (servidor de rendimiento de segunda generación de racksapce 1)
Nginx con Passenger (normalmente utilizo Unicorn, pero nunca he tenido problemas en ninguna de las aplicaciones que implementé con Passenger)
Ruby 2.1.5 (usando rvm)
Rieles 4.1.7
Postgres
Capistrano 3 (usando las extensiones rvm, migraciones, precompilación de activos, etc.)

Lo que he intentado:

cd en el directorio de la aplicación:

cd /home/deployer/app_name/current

Lo que carga .rvmrc y muestra que estoy en el gemset correcto, ejecuté el paquete solo por patadas.

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

Cada vez, recibo un aviso que implica que ''rails c'' no es un comando válido:

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

Una vez más, me he conectado a cientos de consolas de producción tanto en nginx / apache desplegadas con versiones antiguas y nuevas de Unicorn y en su mayoría versiones anteriores de Passenger.

Esta es la primera vez que recibo este mensaje, y la consola es lo ÚNICO que parece estar roto, ¡todo lo demás funciona bien! la aplicación es en vivo y funciona muy bien.

Sé que lo primero que se debe sugerir es que no estoy ejecutando la producción de rieles c desde el directorio de la aplicación; he copiado en el directorio correcto al menos 10 veces y cargado manualmente el gemset correcto, este no es el problema.

No puedo entender por qué funciona bien en el desarrollo, pero no en la producción. Sé que solía haber un directorio de scripts hace un tiempo (¿tal vez los carriles 2?) - ¿Todavía hay un directorio que contiene los comandos de scripts para los rieles que pueden estar dañados?

¿Alguien ha experimentado esto antes o tiene alguna sugerencia?

Siento que me estoy perdiendo algo.

Answer 1

Comprueba si tienes alguno de estos archivos y prueba a eliminarlos:

• script/rails
• bin/rails

Answer 2

Ok, encontré el problema ... @stoodfarback estaba bastante cerca, pero pensé que la causa del problema debía mencionarse para otros que pudieran encontrar lo mismo.

Básicamente estoy usando una versión más nueva de Capistrano (3.3.5) que he usado en el pasado y (de forma predeterminada) agrega ''bin'' a la lista de directorios compartidos que se enlaza en cada implementación.

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

Por lo tanto, la secuencia de comandos de implementación creó un nuevo directorio en bin compartidos compartidos (que estaba vacío) y faltaban los archivos utilizados para iniciar el servidor y la consola de rails. Obviamente todavía estaban allí en desarrollo, por lo que solo afectó la producción.

Se eliminó ''bin'' de la lista linked_dirs y todo funciona ahora como se esperaba.

ahora se ve así:

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

He notado en las últimas versiones de Capistrano que he usado, el formato y los valores predeterminados de linked_dirs cambian un poco, pero nunca había visto bin en esa lista. No estoy muy seguro de por qué bin debería enlazarse simbólicamente ... solo tiene los archivos de rieles predeterminados y no puedo pensar en por qué tendrían que ser eliminados del control de código fuente, pero tal vez el equipo de Capistrano tiene una razón.

Espero que esto ayude a alguien.