我對確保nginx始終運行起來感到非常困惑。我對init.d腳本的理解只是啓動和停止nginx。它是否正確？然後在文檔中說它保持守護進程=關閉;現在Nginx和runit ....什麼是最佳做法
，我想用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？
Nginx具有管理工作進程的主進程。它保持自己運行。通過讓nginx運行在前臺並讓其他應用程序管理很難重新發明輪子。
/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將處理得很好。
謝謝...所以...很酷...我沒有做任何事情我收集。 – Tampa 2012-03-06 13:12:48
我不明白這一點，主進程如何保持自己運行，以防萬一它崩潰？ – Paolo 2012-10-01 00:37:23
使用專用監督程序（如runit）的整個想法是不要重複發明輪子。從積極的角度來看，至少nginx在其重新創建的幫助下提供了不間斷的升級，所以如果你需要它，這可能是一個好主意。 – squiddle 2014-05-02 09:55:58