Nginx 和 runit ......什么是最佳实践

Question

我对确保 nginx 始终处于运行状态感到困惑。我的理解 init.d 脚本只是启动和停止 nginx。这样对吗？然后在文档中它说保持守护进程=关闭；

现在，我想使用 runit，下面是我的 runit 运行脚本:

#!/bin/sh
exec /etc/init.d/nginx start

我注意到总是会创建一个新的 PID。

所以总而言之:
1) 我在 nginx 文件中没有这个语句:

daemon = off;

2) 我正在使用上面的 runit 脚本，但它总是会创建一个新的 PID。

那么......确保nginx始终运行的最佳实践是什么。

顺便说一下，我正在使用 monit，但会使用 runit 来拥有 hte 守护程序。

作为测试，我确实使用 killall -9 nginx 杀死了 nginx，并且我做了一个 ps aux | grep nginx 并注意到我得到了新的 pid。所以..我还需要运行吗？

Answer 1

下的脚本 /etc/init.d与 sysvinit 相关联，这是 UNIX 服务管理的一种古老但不幸的是相当 splinter 的方法。看，UNIX 下的进程形成一棵树:每个进程都有一个父进程，即启动它的进程。父进程对其子进程有很多控制权，重要的是在子进程终止时会收到通知。如果您是它的父进程，那么保持进程运行或关闭它实际上是微不足道的。

问题来了:一个 sysvinit 服务脚本启动一个服务，然后退出，让服务继续运行。服务的父进程消失了，这使得定位和跟踪服务变得困难——当 sysvinit 脚本被要求停止服务时，它需要使用不可靠的信息来确定应该停止哪个进程。

在正确的服务管理方法下，如在 runit 和 daemontools 中使用的那样，服务由监督进程运行，这些进程在启动服务后仍然存在。由于服务是一个子进程，主管进程知道它是否正在运行，是否崩溃，以及在哪里可以找到它以向它发送信号。

因此，在 runit 脚本中，正确的做法是运行 nginx 本身，而不是 init.d 脚本。这很容易做到。然而，默认情况下 nginx 守护进程本身，这意味着它故意从其父进程“逃脱”并且变得很难跟踪。幸运的是，该行为可以关闭，这就是 daemon off; 的目的。配置选项。因此，nginx 的有效 runit 脚本如下所示:

#!/bin/sh
exec /usr/sbin/nginx -g "daemon off;"

简短而甜蜜。 runit 可以很好地管理这种安排——它会保持 nginx 运行，你可以用 sv 控制它。 .例如， sv hup nginx告诉 nginx 重新加载它的配置。当然，如果nginx崩溃重启，或者故意用 sv restart nginx要求重启，PID会发生变化。 ，但 runit 会处理得很好。

(顺便说一句， never ever ever use kill -9 , ever.)