无法在生产服务器上启动Rails 4控制台

Question

无法在生产服务器上启动Rails 4控制台

ruby-on-railsrubyruby-on-rails-4consoleproduction

36

遇到了奇怪的问题，需要帮助。

我在尝试在生产服务器上启动rails console，但它表现出来好像rails c命令不存在。

值得一提的是，我已经是一名4年的rails开发者，在其他大量的服务器上做这个也从没问题过。在这台服务器上，我可以使用RAILS_ENV=production操作来删除、创建、迁移、填充数据库，应用程序也能正常地在线上运行而没有任何问题。

设备：

Ubuntu 14.04（racksapce第二代performance 1服务器）
带有Passenger的Nginx（通常我使用Unicorn，在我部署的所有应用程序中都没有问题）
Ruby 2.1.5（使用rvm）
Rails 4.1.7
Postgres
Capistrano 3（使用rvm、migrations、asset-precompilation等扩展）

我尝试过：

cd进入应用程序目录：

cd /home/deployer/app_name/current

这个命令会加载.rvmrc文件并显示我所在的正确的gemset，只是为了试试运行了bundle命令。

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' 不是一个有效的命令：

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

我曾经登录过数百个生产控制台，其中包括使用旧版本和新版本的Unicorn和大多数较旧版本的Passenger部署的nginx/apache。

这是我第一次收到这个消息，而且控制台似乎是唯一出现问题的地方 - 其他所有东西都运行正常！应用程序正在运行并且表现良好。

我知道首先建议的是我没有从应用程序目录运行"rails c production" - 我已经至少10次进入了正确的目录并手动加载了正确的gemset，这不是问题所在。

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

是否有人以前遇到过这种情况或有任何建议？

我觉得我漏掉了什么。

- johndavid400

其他命令是否按预期工作？（rails server...）rails -v 告诉你什么？是 4.1.7 吗？ - wpp

不，rails s和rails server都显示我上面描述的相同的“Usage:”消息。而rails -v返回：Rails 4.1.7。 - johndavid400

2个回答

2

检查是否有以下文件，并尝试删除它们：

script/rails
bin/rails

- stoodfarback

没有脚本目录，而bin目录为空。 - johndavid400

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- johndavid400 · Accepted Answer

好的，找到了问题所在... @stoodfarback 接近了问题，但我认为需要提及问题的原因，以便其他可能遇到同样问题的人。

基本上，我正在使用比过去更新的Capistrano版本（3.3.5），它（默认情况下）会将'bin'添加到每次部署时要创建符号链接的共享目录列表中。

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

因此，部署脚本在 shared 目录中创建了一个名为 bin 的新目录（其中为空），用于启动 Rails 服务器和控制台的文件丢失了。它们显然仍然存在于开发环境中，因此只影响了生产环境。

将 'bin' 从 linked_dirs 列表中删除，现在一切都按预期工作。

现在看起来是这样的：

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

我注意到在我使用的最近几个 Capistrano 版本中，linked_dirs 的格式和默认值一直在变化，但我从未见过 bin 在那个列表中。不太确定为什么 bin 需要被建立符号链接...它只有默认的 Rails 文件，我想不出为什么它们需要从源代码控制中移除，但也许是因为 Capistrano 团队有原因。

希望这能帮助某些人。