好吧，这让我的大脑融化了。这可能与我不了解 Upstart 以及我应该了解的事实有关。对于这么长的问题提前致歉。

我正在尝试使用 Upstart 来管理 Rails 应用程序的 Unicorn 主进程。这是我现在的 /etc/init/app.conf :

description "app"

start on runlevel [2]
stop on runlevel [016]

console owner

# expect daemon

script
  APP_ROOT=/home/deploy/app
  PATH=/home/deploy/.rbenv/shims:/home/deploy/.rbenv/bin:$PATH
  $APP_ROOT/bin/unicorn -c $APP_ROOT/config/unicorn.rb -E production # >> /tmp/upstart.log 2>&1
end script

# respawn

效果很好 - Unicorns 启动得很好。不好的是检测到的 PID 不是 Unicorn master 的，而是 sh 的。过程。这本身也不是那么糟糕——如果我没有使用自动的 unicorn 零停机部署策略的话。因为在我发送 -USR2 后不久对我的 unicorn 主人来说，一个新主人诞生了，旧主人死了……sh也是如此。过程。所以 Upstart 认为我的工作已经死了，我不能再用 restart 重新开始它了或者用 stop 停止它如果我愿意的话。

我试过配置文件，尝试将 -D 添加到 Unicorn 行(如下所示:$APP_ROOT/bin/unicorn -c $APP_ROOT/config/unicorn.rb -E production -D)以守护 Unicorn，并且我添加了 expect daemon行，但这也不起作用。我试过了 expect fork以及。所有这些事情的各种组合可能导致 start和 stop挂起，然后 Upstart 对工作状态感到非常困惑。然后我必须重新启动机器来修复它。

我认为 Upstart 在检测 Unicorn 何时/是否 fork 时遇到问题，因为我使用的是 rbenv + ruby-local-exec shebang 在我的$APP_ROOT/bin/unicorn脚本。在这里:

#!/usr/bin/env ruby-local-exec
#
# This file was generated by Bundler.
#
# The application 'unicorn' is installed as part of a gem, and
# this file is here to facilitate running it.
#

require 'pathname'
ENV['BUNDLE_GEMFILE'] ||= File.expand_path("../../Gemfile",
  Pathname.new(__FILE__).realpath)

require 'rubygems'
require 'bundler/setup'

load Gem.bin_path('unicorn', 'unicorn')

另外，ruby-local-exec脚本看起来像这样:

#!/usr/bin/env bash
#
# `ruby-local-exec` is a drop-in replacement for the standard Ruby
# shebang line:
#
#    #!/usr/bin/env ruby-local-exec
#
# Use it for scripts inside a project with an `.rbenv-version`
# file. When you run the scripts, they'll use the project-specified
# Ruby version, regardless of what directory they're run from. Useful
# for e.g. running project tasks in cron scripts without needing to
# `cd` into the project first.

set -e
export RBENV_DIR="${1%/*}"
exec ruby "$@"

所以有一个 exec在那里我很担心。它启动了一个 Ruby 进程，该进程启动了 Unicorn，它可能会也可能不会 self 守护，这一切都发生在 sh 上。首先是过程...这让我严重怀疑 Upstart 跟踪所有这些废话的能力。

我正在尝试做的事情是否可行？据我了解，expect Upstart 中的节只能被告知(通过 daemon 或 fork )最多有两个 fork 。

最佳答案

您的 upstart 作业需要进行配置，以便 upstart 确切知道它 fork 了多少次。而且它只能 fork 一次或两次，不能再多了。

在 unix 领域，有两个关键的系统调用有助于运行程序:fork和 exec .

fork 复制调用它的进程。一个进程调用 fork，并将控制权返回给两个进程。每个进程都必须根据 fork 返回的值来识别它是(父进程还是子进程)(有关详细信息，请参见手册页)。

exec 运行一个新程序，替换调用 exec 的进程。

当您简单地在 shell 中运行命令时，shell 调用 fork 以创建一个具有自己的 id 的新进程，并且该新进程(在一些设置之后)立即调用 exec 启动您键入的命令。这就是大多数程序运行的方式，无论是通过 shell 还是您的窗口管理器或其他什么。 查看system C 中的函数，它在大多数脚本语言中也有变体。

如果您认为它效率低下，那么您可能是对的。这就是从昔日以来在 unix 中完成的方式，显然没有人愿意改变它。原因之一是在 exec 上有很多东西没有被替换，包括(有时)打开的文件，以及进程的用户和组 ID。

另一个原因是为了使 fork 高效，他们付出了很多努力，实际上他们做得很好 - 在现代 unix 中(在 CPU 的帮助下)fork 实际上复制了很少的过程。我想没有人愿意放弃所有这些工作。

并且，(暂停效果)进程 pid。

演示:

mslade@mickpc:~$ echo $$
3652
mslade@mickpc:~$ bash
mslade@mickpc:~$ echo $$
6545
mslade@mickpc:~$ exec bash
mslade@mickpc:~$ echo $$
6545
mslade@mickpc:~$ exit
exit
mslade@mickpc:~$ echo $$
3652

大多数流行语言都有 fork 和 exec 的变体，包括 shell、C、perl、ruby 和 python。但不是 Java。

因此，考虑到所有这些，要让你的 upstart 工作顺利进行，你需要做的是确保它 fork 的次数与 upstart 认为的相同。

ruby-local-exec 中的 exec 行实际上是一件好事，它可以防止 fork 。此外，load 不会启动新进程，它只是将代码加载到现有的 ruby​​ 解释器中并运行它。

但是您的 shell 脚本会在这一行 fork :

$APP_ROOT/bin/unicorn -c $APP_ROOT/config/unicorn.rb -E production # >> /tmp/upstart.log 2>&1

为了防止这种情况，您可以将其更改为

exec $APP_ROOT/bin/unicorn -c $APP_ROOT/config/unicorn.rb -E production # >> /tmp/upstart.log 2>&1

如果你这样做，AFAICT unicorn 根本不应该 fork ，你也不需要告诉 upstart 期待 fork 。

关于ruby-on-rails - 使用 Upstart 管理 Unicorn w/rbenv + bundler binstubs w/ruby-local-exec shebang，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8667425/