无法在生产服务器上启动rails 4控制台 [英] Cannot start rails 4 console on production server

问题描述

有一个奇怪的问题，需要帮助。

Having a weird issue and need help.

我试图在生产服务器上启动rails控制台，它的行为像rails c命令不存在。

I am trying to start a rails console on a production server and it is acting like the rails c command does not exist.

FWIW，我一直是一个rails开发人员4年，这一直在大量的其​​他服务器，没有问题。在这个服务器上，我可以删除，创建，迁移，种子数据库没有任何问题（使用RAILS_ENV =生产），和应用程序工作正常生活没有任何问题。

FWIW, I have been a rails developer for 4 years and do this all the time on a plethora of other servers without issue. On this server, I can drop, create, migrate, seed the database with no problems (using RAILS_ENV=production), and the app works fine live without any issues.

设置：

Ubuntu 14.04（racksapce第二代性能1服务器） br>
Nginx with Passenger（我通常使用Unicorn，但在使用Passenger部署的任何应用程序中都没有问题）

Ruby 2.1.5（使用rvm）

Rails 4.1.7

Postgres

Capistrano 3（使用rvm，migrations，asset-precompilation等扩展）

Ubuntu 14.04 (racksapce 2nd gen performance 1 server)
Nginx with Passenger (I typically use Unicorn, but have never had a problem on any of the apps I have deployed with Passenger)
Ruby 2.1.5 (using rvm)
Rails 4.1.7
Postgres
Capistrano 3 (using the rvm, migrations, asset-precompilation, etc. extensions)

我试过的：

cd到应用程序目录：

cd into app directory:

cd /home/deployer/app_name/current

其中加载.rvmrc并显示我在正确的gemset，运行捆绑只是为了踢。

Which loads .rvmrc and shows that I am in the correct gemset, ran bundle just for 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

每次，我得到一个通知，意味着'rails c'不是有效命令：

Every time, I get a notice that implies 'rails c' is not a valid command:

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。

Again, I have logged into hundreds of production consoles on both nginx/apache deployed with old and new versions of both Unicorn and mostly older versions of Passenger.

这是我第一次得到这个消息，控制台是唯一的东西，似乎被打破 - 一切工作正常！该应用程序是现场和工作伟大。

This is the first time I have ever gotten this message, and the console is the ONLY thing that seems to be broken - everything else works fine! the app is live and works great.

我知道第一件事建议是，我没有运行rails c生产从应用程序目录 - 我有cd' d进入正确的目录至少10次，手动加载正确的gemset，这不是问题。

I know that the first thing to be suggested is that I am not running rails c production from the app directory - I have cd'd into the correct directory at least 10 times and manually loaded the correct gemset, this is not the issue.

无法弄清楚为什么它在开发中正常工作，不在生产。我知道以前曾经有一个脚本目录一个回来（也许rails 2？） - 还有一个目录，其中包含可能已损坏的rails的脚本命令。

Can't figure out why it works fine in development, but not in production. I know there used to be a scripts directory a while back (maybe rails 2?)- Is there still a directory that contains the script commands for rails that may have been corrupted?

有没有人经历过这个或有任何建议？

Has anyone ever experienced this before or have any suggestions?

我觉得我缺少某些东西。

I feel like I am missing something.

推荐答案

好吧，发现问题... @stoodfarback非常接近，但我认为这个问题的原因需要提及的人可能遇到同样的事情。

Ok, found the issue... @stoodfarback was pretty close, but I thought the cause of the issue needed to be mentioned for others who might encounter the same thing.

基本上，我使用的是比我过去使用的更新版本的Capistrano（3.3.5），它（默认情况下）添加bin到共享目录列表

Basically I am using a newer version of Capistrano (3.3.5) than I have used in the past and it (by default) adds 'bin' to the list of shared directories that it symlinks on each deploy.

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

因此，部署脚本在共享中创建了一个新目录，称为bin（它为空），并且用于启动rails服务器和控制台的文件丢失。

So the deploy script created a new directory in shared called bin (which was empty) and the files used to launch rails server and console were missing. They were obviously still there in development, so it only affected production.

从linked_dirs列表中删除了bin，一切都按预期工作。

Removed 'bin' from the linked_dirs list and everything now works as expected.

现在看起来像：

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

我注意到了我使用的Capistrano的最后几个版本，linked_dirs的格式和默认值不断变化，但我从来没有见过这个列表中的bin。不真正确定为什么bin将需要符号链接...它只有默认rails文件，我不能想到为什么他们需要从源代码控制中删除，但也许Capistrano团队有一个原因。

I have noticed on the last few versions of Capistrano that I have used, the format and defaults for linked_dirs keeps changing quite a bit, but I had never seen bin in that list. Not really sure why bin would need to be symlinked... it only has the default rails files and I can't think of why they would need to be removed from source control, but maybe the Capistrano team has a reason.

希望这有助于某人。

这篇关于无法在生产服务器上启动rails 4控制台的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！