Unicorn Restart - master 启动失败，查看 stderr 日志了解详情答案

【问题标题】：Unicorn Restart - master failed to start, check stderr log for detailsUnicorn Restart - master 启动失败，查看 stderr 日志了解详情
【发布时间】：2017-10-09 04:30:20
【问题描述】：

使用 capistrano 部署时出错

DEBUG [aaaad896] Command: cd /home/dev/PROJECT-NAME/current && ( export RAILS_ENV="production" ; ~/.rvm/bin/rvm default do bundle exec unicorn -c /home/dev/PROJECT-NAME/current/config/unicorn.rb -E deployment -D  )
DEBUG [aaaad896]    master failed to start, check stderr log for details
(Backtrace restricted to imported tasks)
cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing as dev@XX.XXX.XXX.XX: bundle exit status: 1
bundle stdout: Nothing written
bundle stderr: master failed to start, check stderr log for details

其他日志。

Errno::EADDRINUSE: Address already in use - bind(2) for 0.0.0.0:8080
  /home/dev/PROEJCT-NAME/shared/bundle/ruby/2.3.0/gems/unicorn-5.1.0/lib/unicorn/socket_helper.rb:149:in `bind'

unicorn.rb 文件：unicorn.rb

deploy.rb 文件 deploy.rb

默认（nginx/site-enables/default）文件：default

每次我在 capistrano 中遇到此错误时都会重新启动独角兽。那么我该如何解决呢？

【问题讨论】：

标签： ruby-on-rails ruby nginx unicorn capistrano3

【解决方案1】：

问题是您在端口 8080 中侦听了另一个服务，这就是您的日志所说的。如果您使用的是 linux，您可以检查它使用的是哪个服务lsof -i:8080。这将告诉您谁在使用该端口。如果您可以终止服务，请执行此操作，如果不能，只需更改配置文件中的端口即可。

【讨论】：

部署后，我对代码进行了一些更改，并再次使用“cap production deploy”命令进行部署。（服务器已经在运行）但是那个时候我得到了错误，因为端口已经用于独角兽。我想在运行 cap production deploy 时重新启动我的独角兽。
在部署上限后，您可以通过多种方式重新启动独角兽。你可以搜索谷歌看看，但是这些answers对你有帮助吗？

【解决方案2】：

要杀死一个已经在运行的进程，你可以使用

ps aux | grep unicorn

这会列出类似的东西

deployer  3807  2.8  9.3 369964 94996 ?        Sl   12:51   0:03 unicorn master -D -c /home/deployer/apps/cb_app/current/config/unicorn.rb -E staging

deployer  3816  0.0  8.5 369964 87040 ?        Sl   12:51   0:00 unicorn worker[0] -D -c /home/deployer/apps/cb_app/current/config/unicorn.rb -E staging

deployer  3818  0.0  8.5 369964 87200 ?        Sl   12:51   0:00 unicorn worker[1] -D -c /home/deployer/apps/cb_app/current/config/unicorn.rb -E staging

然后你可以用

杀死他们

kill 3807

现在再次尝试部署，看看 master 是否启动。

【讨论】：

【解决方案3】：

有时它只是关于权限，因为独角兽重新启动它需要写入日志。检查 /log 的文件夹权限并使其对所有人都可写。

【讨论】：

【解决方案4】：

我遇到了同样的问题，是的，关于权限，早些时候当 docker GitLab 容器（或服务器）关闭时，我确实对本地机器上的日志和数据文件（它们是卷）的权限进行了一些更改.由于更改了权限，GitLab 容器在启动时无法写入任何内容，因此出现此错误。因为我已经恢复了我所做的更改。它对我来说很好用。

【讨论】：