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的方式，但会跑到自己的hte守护进程。

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

Answer 1

Nginx具有管理工作进程的主进程。它保持自己运行。通过让nginx运行在前台并让其他应用程序管理很难重新发明轮子。

Answer 2

/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崩溃并且重新启动，或者你故意要求它重新启动sv restart nginx，那么PID将会改变，但是runit将处理得很好。

_{（顺便说一句，never ever ever use kill -9, ever.）}