无法在生产服务器上启动 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，我已经做了 4 年的 Rails 开发人员，并且一直在大量其他服务器上这样做而没有问题.在这台服务器上，我可以毫无问题地删除、创建、迁移、播种数据库(使用 RAILS_ENV=production)，并且该应用程序可以正常运行，没有任何问题.

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(机架空间第二代性能 1 服务器)
Nginx 与Passenger(我通常使用Unicorn，但在我使用Passenger 部署的任何应用程序上从未遇到过问题)
Ruby 2.1.5(使用 rvm)
Rails 4.1.7
Postgres
Capistrano 3(使用 rvm、迁移、资产预编译等扩展)

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 /home/deployer/app_name/current

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

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.

我知道要建议的第一件事是我没有从 app 目录运行 rails c production - 我已经 cd 到正确的目录中至少 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?

我觉得我错过了什么.

推荐答案

好的，找到问题了...@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.

从 links_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.

希望这对某人有所帮助.

Hope this helps someone.

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