使用 Upstart 管理 Unicorn（带有 rbenv + bundler binstubs 和 ruby-local-exec shebang）

Question 1

事实上，upstart 的一个限制是它无法跟踪执行 unicorn 所做工作的守护进程，也就是 fork/exec 并退出其主进程。信不信由你，sshd 在 SIGHUP 上做同样的事情，如果你仔细查看，就会发现 /etc/init/ssh.conf 确保 sshd 在前台运行。这也是 apache2 仍然使用 init.d 脚本的原因之一。

听起来 gunicorn 在收到 SIGUSR1 时实际上会通过分叉然后退出来将自己变成守护进程。对于任何试图保持进程活动的进程管理器来说，这都会令人困惑。

我认为你有两个选择。1 是在需要时不使用 SIGUSR1 并停止/启动 gunicorn。

另一个选择是不使用 upstart 的 pid 跟踪，只需执行以下操作：

start on ..
stop on ..

pre-start exec gunicorn -D --pid-file=/run/gunicorn.pid
post-stop exec kill `cat /run/gunicorn.pid`

虽然不如 pid 跟踪那么性感，但至少你不必编写整个 init.d 脚本。

（顺便说一句，这与 shebangs/execs 无关。它们的工作方式与运行常规可执行文件一样，因此它们不会导致任何额外的分叉）。

Answer

事实上，upstart 的一个限制是它无法跟踪执行 unicorn 所做工作的守护进程，也就是 fork/exec 并退出其主进程。信不信由你，sshd 在 SIGHUP 上做同样的事情，如果你仔细查看，就会发现 /etc/init/ssh.conf 确保 sshd 在前台运行。这也是 apache2 仍然使用 init.d 脚本的原因之一。

听起来 gunicorn 在收到 SIGUSR1 时实际上会通过分叉然后退出来将自己变成守护进程。对于任何试图保持进程活动的进程管理器来说，这都会令人困惑。

我认为你有两个选择。1 是在需要时不使用 SIGUSR1 并停止/启动 gunicorn。

另一个选择是不使用 upstart 的 pid 跟踪，只需执行以下操作：

start on ..
stop on ..

pre-start exec gunicorn -D --pid-file=/run/gunicorn.pid
post-stop exec kill `cat /run/gunicorn.pid`

虽然不如 pid 跟踪那么性感，但至少你不必编写整个 init.d 脚本。

（顺便说一句，这与 shebangs/execs 无关。它们的工作方式与运行常规可执行文件一样，因此它们不会导致任何额外的分叉）。

Question 2

我选择了一个与 SpamapS 略有不同的解决方案。我也在运行一个由 Upstart 管理的 preload_app = true 的应用程序。

当我自己想解决这个问题时，我一直在使用 Upstart 的“exec”来启动我的应用程序（“exec bundle exec unicorn_rails blah blah”）。然后我发现了你的问题，这让我意识到，我可以使用脚本节来指定我的可执行文件，而不是使用 Upstart 的“exec”，该脚本节将在其自己的进程中运行，即 Upstart 将监视的进程。

因此，我的 Upstart 配置文件包括以下内容：

respawn

script
  while true; do
    if [ ! -f /var/www/my_app/shared/pids/unicorn.pid ]; then
      # Run the unicorn master process (this won't return until it exits).
      bundle exec unicorn_rails -E production -c /etc/unicorn/my_app.rb >>/var/www/my_app/shared/log/unicorn.log
    else
      # Someone restarted the master; wait for the new master to exit.
      PID=`cat /var/www/my_app/shared/pids/unicorn.pid`
      while [ -d /proc/$PID ]; do
        sleep 2
      done
      # If we get here, the master has exited, either because someone restarted
      # it again (in which case there's already a new master running), or
      # it died for real (in which case we'll need to start a new process).
      # The sleep above is a tradeoff between polling load and mimizing the
      # restart delay when the master dies for real (which should hopefully be
      # rare).
    fi
  done
end script

我的 Unicorn 配置文件中的 before_fork 与 Unicorn 站点示例中所建议的一样，http://unicorn.bogomips.org/examples/unicorn.conf.rb：

before_fork do |server, worker|
  ActiveRecord::Base.connection.disconnect! if defined?(ActiveRecord::Base)

  old_pid = '/var/www/my_app/shared/pids/unicorn.pid.oldbin'
  if server.pid != old_pid
    begin
      sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
      Process.kill(sig, File.read(old_pid).to_i)
    rescue Errno::ENOENT, Errno::ESRCH
      # someone else did our job for us
    end
  end
  sleep 0.5
end

因此：在启动时，Upstart 脚本找不到 pidfile，因此它运行 unicorn_rails，并持续运行。

稍后，我们重新部署我们的应用程序，并且 Capistrano 任务通过以下方式触发应用程序重启：

kill -USR2 `cat /var/www/my_app/shared/pids/unicorn.pid`

这告诉旧的 Unicorn 主服务器启动一个新的 Unicorn 主服务器进程，并且当新主服务器启动工作进程时，Unicorn before_fork 块向旧的主服务器发送 TTOU 信号以关闭旧的工作进程（优雅地），然后在只剩下一个工作进程时退出。

QUIT 会导致旧主进程退出（但只有在有新工作进程处理负载时才会退出），因此 unicorn 脚本中会返回“bundle exec unicorn_rails”。然后该脚本会循环，查看现有的 pidfile，并等待进程退出。它直到下一次部署才会退出，但如果它退出，我们会再次循环；主进程死机时，我们也会再次循环。

如果 bash 脚本本身终止，Upstart 将重新启动它，因为这是它正在监视的进程（如您所见status my_app- Upstart 报告 bash 脚本的 PID）。您仍然可以使用stop my_app或restart my_app，但它们不会执行任何优雅的操作。

Answer