工头开始:退出代码0错误

时间:2016-05-02 01:59:56

标签: ruby foreman padrino

我正在尝试从我的Windows机器启动我的Ruby项目,当我通过SSH进入我的流浪盒时,导航到领班,然后尝试运行foreman start我收到以下错误。

01:54:14 web.1  | started with pid 12002
01:54:15 web.1  | BUNDLE-EXEC(1)                                                                                                                 BUNDLE-EXEC(1)
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  | NAME
01:54:15 web.1  |        bundle-exec - Execute a command in the context of the bundle
01:54:15 web.1  |
01:54:15 web.1  | SYNOPSIS
01:54:15 web.1  |        bundle exec [--keep-file-descriptors] command
01:54:15 web.1  |
01:54:15 web.1  | DESCRIPTION
01:54:15 web.1  |        This command executes the command, making all gems specified in the Gemfile(5) available to require in Ruby programs.
01:54:15 web.1  |
01:54:15 web.1  |        Essentially,  if  you would normally have run something like rspec spec/my_spec.rb, and you want to use the gems specified in the Gem‐
01:54:15 web.1  |        file(5) and installed via bundle install(1) bundle-install.1.html, you should run bundle exec rspec spec/my_spec.rb.
01:54:15 web.1  |
01:54:15 web.1  |        Note that bundle exec does not require that an executable is available on your shell´s $PATH.
01:54:15 web.1  |
01:54:15 web.1  | OPTIONS
01:54:15 web.1  |        --keep-file-descriptors
01:54:15 web.1  |               Exec in Ruby 2.0 began discarding non-standard file descriptors. When this flag is passed, exec will revert to the  1.9  behav‐
01:54:15 web.1  |               iour of passing all file descriptors to the new process.
01:54:15 web.1  |
01:54:15 web.1  | BUNDLE INSTALL --BINSTUBS
01:54:15 web.1  |        If  you  use  the  --binstubs  flag  in  bundle install(1) bundle-install.1.html, Bundler will automatically create a directory (which
01:54:15 web.1  |        defaults to app_root/bin) containing all of the executables available from gems in the bundle.
01:54:15 web.1  |
01:54:15 web.1  |        After using --binstubs, bin/rspec spec/my_spec.rb is identical to bundle exec rspec spec/my_spec.rb.
01:54:15 web.1  |
01:54:15 web.1  | ENVIRONMENT MODIFICATIONS
01:54:15 web.1  |        bundle exec makes a number of changes to the shell environment, then executes the command you specify in full.
01:54:15 web.1  |
01:54:15 web.1  |        ·   make sure that it´s still possible to shell out to bundle from inside a command invoked by bundle exec (using $BUNDLE_BIN_PATH)
01:54:15 web.1  |
01:54:15 web.1  |        ·   put the directory containing executables (like rails, rspec, rackup) for your bundle on $PATH
01:54:15 web.1  |
01:54:15 web.1  |        ·   make sure that if bundler is invoked in the subshell, it uses the same Gemfile (by setting BUNDLE_GEMFILE)
01:54:15 web.1  |
01:54:15 web.1  |        ·   add -rbundler/setup to $RUBYOPT, which makes sure that Ruby programs invoked in the subshell can see the gems in the bundle
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |        It also modifies Rubygems:
01:54:15 web.1  |
01:54:15 web.1  |        ·   disallow loading additional gems not in the bundle
01:54:15 web.1  |
01:54:15 web.1  |        ·   modify the gem method to be a no-op if a gem matching the requirements is in the bundle, and to raise a Gem::LoadError if it´s not
01:54:15 web.1  |
01:54:15 web.1  |        ·   Define Gem.refresh to be a no-op, since the source index is always frozen when using bundler, and to prevent gems from the  system
01:54:15 web.1  |            leaking into the environment
01:54:15 web.1  |
01:54:15 web.1  |        ·   Override Gem.bin_path to use the gems in the bundle, making system executables work
01:54:15 web.1  |
01:54:15 web.1  |        ·   Add all gems in the bundle into Gem.loaded_specs
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |    Shelling out
01:54:15 web.1  |        Any  Ruby  code that opens a subshell (like system, backticks, or %x{}) will automatically use the current Bundler environment. If you
01:54:15 web.1  |        need to shell out to a Ruby command that is not part of your current bundle, use the with_clean_env method with a block. Any subshells
01:54:15 web.1  |        created  inside the block will be given the environment present before Bundler was activated. For example, Homebrew commands run Ruby,
01:54:15 web.1  |        but don´t work inside a bundle:
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |            Bundler.with_clean_env do
01:54:15 web.1  |              `brew install wget`
01:54:15 web.1  |            end
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |        Using with_clean_env is also necessary if you are shelling out to a different bundle. Any Bundler commands  run  in  a  subshell  will
01:54:15 web.1  |        inherit the current Gemfile, so commands that need to run in the context of a different bundle also need to use with_clean_env.
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |            Bundler.with_clean_env do
01:54:15 web.1  |              Dir.chdir "/other/bundler/project" do
01:54:15 web.1  |                `bundle exec ./script`
01:54:15 web.1  |              end
01:54:15 web.1  |            end
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |        Bundler provides convenience helpers that wrap system and exec, and they can be used like this:
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |            Bundler.clean_system(´brew install wget´)
01:54:15 web.1  |            Bundler.clean_exec(´brew install wget´)
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  | RUBYGEMS PLUGINS
01:54:15 web.1  |        At present, the Rubygems plugin system requires all files named rubygems_plugin.rb on the load path of any installed gem when any Ruby
01:54:15 web.1  |        code requires rubygems.rb. This includes executables installed into the system, like rails, rackup, and rspec.
01:54:15 web.1  |
01:54:15 web.1  |        Since Rubygems plugins can contain arbitrary Ruby code, they commonly end up activating themselves or their dependencies.
01:54:15 web.1  |
01:54:15 web.1  |        For instance, the gemcutter 0.5 gem depended on json_pure. If you had that version of gemcutter installed (even  if  you  also  had  a
01:54:15 web.1  |        newer version without this problem), Rubygems would activate gemcutter 0.5 and json_pure <latest>.
01:54:15 web.1  |
01:54:15 web.1  |        If  your  Gemfile(5)  also contained json_pure (or a gem with a dependency on json_pure), the latest version on your system might con‐
01:54:15 web.1  |        flict with the version in your Gemfile(5), or the snapshot version in your Gemfile.lock.
01:54:15 web.1  |
01:54:15 web.1  |        If this happens, bundler will say:
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |            You have already activated json_pure 1.4.6 but your Gemfile
01:54:15 web.1  |            requires json_pure 1.4.3. Consider using bundle exec.
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |        In this situation, you almost certainly want to remove the underlying gem with the problematic gem plugin. In general, the authors  of
01:54:15 web.1  |        these plugins (in this case, the gemcutter gem) have released newer versions that are more careful in their plugins.
01:54:15 web.1  |
01:54:15 web.1  |        You can find a list of all the gems containing gem plugins by running
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |            ruby -rubygems -e "puts Gem.find_files(´rubygems_plugin.rb´)"
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |        At  the  very  least, you should remove all but the newest version of each gem plugin, and also remove all gem plugins that you aren´t
01:54:15 web.1  |        using (gem uninstall gem_name).
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |
01:54:15 web.1  |                                                                   March 2016                                                   BUNDLE-EXEC(1)
01:54:16 web.1  | exited with code 0
01:54:16 system | sending SIGTERM to all processes

所有Procfile保持的是:bundle exec padrino start -h 0.0.0.0

当我尝试在我的OSX设备上运行它时,我能够很好地启动该过程。它只是从我的Windows电脑我遇到这个。有没有人碰到这个或知道我错过了什么?

1 个答案:

答案 0 :(得分:0)

显然,在Windows上使用puTTY的区别,以及OSX内置的vagrant ssh需要padrino start -h 0.0.0.0左右的引号。

因此,修复程序正在将Procfile中的bundle exec padrino start -h 0.0.0.0更改为bundle exec 'padrino start -h 0.0.0.0'

相关问题