我对确保 nginx 始终处于启动状态感到很困惑。我对 init.d 脚本的理解只是启动和停止 nginx。这个对吗？然后在文档中说要保持 daemon = off;
现在，我想使用 runit，下面是我的 runit 运行脚本：
#!/bin/sh
exec /etc/init.d/nginx start
我注意到总是会创建一个新的 PID。
总而言之：1）我在nginx文件中没有这个语句：
daemon = off;
2）我正在使用上面的 runit 脚本，但它总是创建一个新的 PID。
那么......确保nginx始终运行的最佳实践是什么。
顺便说一句，我正在使用monit，但会运行它来拥有hte daemon。
作为测试，我确实使用 killall -9 nginx 杀死了 nginx，并且我做了一个 ps aux | grep nginx 并注意到我得到了新的 pid。所以..我还需要runit吗？
下面的脚本/etc/init.d与 sysvinit 相关联，sysvinit 是一种古老但不幸的是相当破碎的 UNIX 服务管理方法。看，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 崩溃并重新启动，或者您故意要求它重新启动，PID 会发生变化sv restart nginx，但 runit 会处理得很好。
（顺便说一句，永远不要使用，永远kill -9。）
Nginx 有一个管理工作进程的主进程。它保持自己运行。通过让 nginx 在前台运行并让其他一些应用程序管理是很糟糕的重新发明轮子。