2015-01-30 4 views
36

Haben ein seltsames Problem und brauchen Hilfe.Kann Schienen 4 Konsole auf Produktionsserver nicht starten

Ich versuche, eine Rails-Konsole auf einem Produktionsserver zu starten, und es verhält sich wie die Schienen c Befehl existiert nicht.

FWIW, ich bin seit 4 Jahren ein Rails-Entwickler und mache dies die ganze Zeit auf einer Vielzahl anderer Server ohne Probleme. Auf diesem Server kann ich die Datenbank löschen, erstellen, migrieren, ohne Probleme erstellen (mit RAILS_ENV = Produktion), und die App funktioniert problemlos und ohne Probleme.

Setup:

Ubuntu 14.04 (racksapce 2nd gen Leistung 1 Server)
Nginx mit Passagiere (ich benutze normalerweise Einhorn, aber hatte noch nie ein Problem auf eine der Apps, die ich mit Passagiere bereitgestellt habe)
Rubin 2.1.5 (unter Verwendung von RVM)
Rails 4.1.7
Postgres
Capistrano 3 (unter Verwendung der RVM, Migrationen, Asset-Vorübersetzung usw. Erweiterungen)

Was ich versucht habe:

cd in App-Verzeichnis:

cd /home/deployer/app_name/current 

Welche .rvmrc lädt und zeigt, dass ich in der richtigen gemset bin, lief Bündel nur für Kicks.

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 

Jedes Mal habe ich eine Mitteilung erhalten, die ‚Schienen c‘ ist kein gültiger Befehl impliziert:

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

Noch einmal, ich habe auf beiden nginx/Apache eingesetzt angemeldet in Hunderte von Produktions Konsolen mit alte und neue Versionen von Unicorn und meist ältere Versionen von Passenger.

Dies ist das erste Mal, dass ich diese Nachricht bekommen habe, und die Konsole ist das EINZIGE, was kaputt zu sein scheint - alles andere funktioniert gut! Die App ist live und funktioniert super.

Ich weiß, dass die erste Sache, die vorgeschlagen wird, ist, dass ich keine Schienen c Produktion aus dem App-Verzeichnis laufen habe - ich habe mindestens 10 mal in das richtige Verzeichnis cd'd und manuell geladen das richtige Gemset, das ist nicht Das Thema.

Ich kann nicht herausfinden, warum es in der Entwicklung gut funktioniert, aber nicht in der Produktion. Ich weiß, dass es vor einiger Zeit ein Skripte-Verzeichnis gab (vielleicht Rails 2?) - Gibt es noch ein Verzeichnis, das die Skript-Befehle für Rails enthält, die möglicherweise beschädigt wurden?

Hat jemand schon einmal das erlebt oder irgendwelche Vorschläge?

Ich fühle mich wie ich etwas vermisse.

+0

Funktionieren die anderen Befehle wie erwartet? ('rails server' ...) Was sagt rails -v dir? Ist es 4.1.7? – wpp

+0

nein, rails s und rails server zeigen beide die gleiche "Usage:" Meldung an wie oben beschrieben. Und rails -v gibt zurück: Rails 4.1.7 – johndavid400

Antwort

64

Ok, fand das Problem ... @stoodfarback ziemlich nahe war, aber ich Ich dachte, die Ursache des Problems müsse für andere erwähnt werden, die dasselbe erleben könnten.

Grundsätzlich verwende ich eine neuere Version von Capistrano (3.3.5) als ich in der Vergangenheit verwendet habe und es fügt standardmäßig 'bin' der Liste der freigegebenen Verzeichnisse hinzu, die es bei jedem Deploy symbolisiert.

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

So erstellt das deploy Skript ein neues Verzeichnis in gemeinsamen genannt ist (die leer war) und die Dateien verwendet Schienen-Server und Konsole starten fehlten. Sie waren offensichtlich immer noch in der Entwicklung, so dass nur die Produktion betroffen war.

Entfernte 'bin' aus der Linked_dirs-Liste und alles funktioniert nun wie erwartet.

sieht nun wie:

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

ich auf den letzten Versionen von Capistrano bemerkt haben, die ich verwendet habe, das Format und die Standardwerte für linked_dirs hält ziemlich viel ändern, aber ich hatte, dass nie bin gesehen Liste. Ich bin mir nicht wirklich sicher, wieso bin muss symlinked sein ... es hat nur die Standard-Rails-Dateien und ich kann mir nicht vorstellen, warum sie aus der Quellcodeverwaltung entfernt werden müssten, aber vielleicht hat das Capistrano-Team einen Grund.

Ich hoffe, das hilft jemandem.

+4

Vielen Dank für diese, sehr hilfreiche Erklärung! –

+1

Brilliant! Vielen Dank. – oct4th

2

Überprüfen Sie, ob Sie eine dieser Dateien haben und versuchen, sie zu löschen:

  • script/rails
  • bin/rails
+0

Es gibt kein Skriptverzeichnis und das Verzeichnis bin ist leer. – johndavid400

Verwandte Themen