守護程序啟動腳本的最大允許啟動時間是多少？

守護程序啟動腳本的最大允許啟動時間是多少？

我確實有一個 tomcat 伺服器需要很長時間才能啟動，我可以在啟動腳本中包含邏輯來檢查服務是否成功啟動。

儘管如此，我還是擔心守護程序啟動可能存在無限循環，如果將其配置為在啟動時執行，這甚至可能影響系統的啟動。

不過，我確實想返回正確的退出消息（成功/失敗）。

我可以實現一些超時邏輯，但我不知道守護程序腳本的可接受或不可接受的啟動時間。

此外，在該服務仍在初始化時停止其他服務的初始化也沒有太大意義。

系統啟動腳本沒有“最大允許啟動時間”。但是，對於長時間執行的腳本，會發生的情況是，啟動腳本通常會將需要很長時間的程序作為後台程序甚至“at”程序分離出來。因此，這可以防止執行緩慢的程序在系統“準備好”執行之前花費很長時間。

如前所述，守護程序沒有最大或可配置的啟動時間。如果您認為該守護程序導致其他守護程序啟動，您可以在最後更改其啟動順序。

要調試問題，我現在可以想到三種方法。

1. 明顯的步驟是為應用程序啟用調試日誌。我主要使用 RHEL，並且/etc/sysconfig/<daemon-name>可以設置日誌級別。

2. 當你手動啟動守護程序時，用 strace 啟動它。

strace -ffttTo /tmp/daemon.out /etc/init.d/daemon start

現在在 daemon.out 文件中，觀察每個系統呼叫結束時列印的時間。以微秒為單位。找出消耗最多時間的呼叫。

當你發現時，再次啟動守護程序，這次使用 ltrace。既然您知道了有問題的系統呼叫，請弄清楚它在哪個庫中卡住了。

3）編寫一個systemtap腳本。除非使用者有一些使用 stap 編寫/調試的經驗，否則這不是那麼容易。

probe syscall.*
{
( (pid) == target() )
printf("%s\n",name)
}

這將顯示目標 pid 將拋出的所有系統呼叫。

注意 - 不要首先選擇 stap。我剛剛提到它是因為它是一個很棒的核心調試工具，我還沒有在網站上看到它的引用（或者可能被忽略了）。您需要安裝 kernel-debuginfo、kernel-debuginfo-common、kernel-devel、systemtap 包。然後將腳本執行為

stap <script_name.stp> -x pid

我們可以進一步檢測有問題的系統呼叫。

http://sourceware.org/systemtap/documentation.html

引用自：https://serverfault.com/questions/512304