對於自行實現的很多服務，很多人喜歡用一個專門的監控進程來監控自己的服務，為了防止監控進程也崩掉，甚至使用了經典的雙進程監控。不說別的，光編寫調試這個雙進程就夠我喝一壺的啦，對於我這樣專門寫bug的家伙來講，更是一件揪心的差事。就算有一天，我不再寫bug了，可以操作系統的關卡你又過不了了，難關重重。這些監控程序，不管是單進程還是雙進程，其根本肯定是一個big loop，而且這個big loop中幾乎都要有一個sleep，否則CPU飙升，卻不見得能給真正的服務，淨給了這個big loop，就算沒有sleep，你的cpu核心超級多，也不在乎錢，你可以專門買一個cpu來運行你這個monitor的big loop，然而在這次檢測和下次檢測之間的微小空隙裡面還是會有很多事情可以發生的。比如下列的雙進程序列：
最直接的，假設p1和p2同時運行在兩個cpu上，且序列同步，在t0和t1之間，t0’和t1’之間，p1和p2都被干掉會發生什麼；如果在同一個cpu上運行，事情更簡單，t1和t2之間干掉p1，同時給p2發送sigkill，此時操作系統調度到p2，p2本該從t0開始運行，然而由於內核信號隊列中存在sigkill，它直接就exit啦，之後誰來啟動它們倆。操作系統調度是程序員和管理員控制不了的，它也根本沒有導出給應用層更多的控制權，因此在單cpu情況下，你無法預料調度器會怎樣調度你的monitor，因而就可以設計一個混沌的序列來不斷嘗試干掉你的雙monitor，多cpu情況下，事情更糟糕，注定你要帶著腳鐐跳舞。
因此，雙進程保護在邏輯上並不是很可取的，雖然大體上，對於一般的場合，大家都在用它。問題就出在不管是p1還是p2都是可以在任意時刻被干掉的，如果它們其中之一不會被干掉，事情就解決了。在linux中，init進程不能被干掉，因此可以讓init來充當monitor，實際上它裡面也有一個經典的big loop，可是人家因為有特權，所以多多的sleep一下也是無大礙的。事實上，很多的linux服務都使用了init進程作為了自己的monitor，你只需要編輯一下/etc/inittab就可以了，在這個inittab中，注意最後面的幾行：
1:2345:respawn:/sbin/mingetty tty1
…
這個respawn的含義就是結束了再起來的意思，你只需要將後面再添加幾行這樣的信息即可，你的服務就可以被監控了。需要注意的是，這些行以:分割，第一個字段是一個唯一的id，往下順延即可，具體的信息可以man inittab，定會一目了然，我就不翻譯man手冊了。
