# 停止和重啟 本文檔敘述了在類Unix系統上如何停止和重啟Apache 。 Windows NT/2000/XP/2003的用戶請參見[以服務方式運行Apache](#calibre_link-422) ，Windows 9x/ME用戶則參見[在控制臺中運行Apache](#calibre_link-372) 。 ## 簡介 為了停止或者重新啟動Apache ，你必須向正在運行的`httpd`進程發送信號。有兩種發送信號的方法。第一種方法是直接使用UNIX的`kill`命令向運行中的進程發送信號。你也許你會注意到你的系統里運行著很多`httpd`進程。但你不應該直接對它們中的任何一個發送信號，而只要對已經在`PidFile`中記載下了自身PID的父進程發送信號。也就是說，你不必對父進程以外的任何進程發送信號。你可以向父進程發送三種信號：`TERM`、`HUP`、`USR1` ，我們過一會兒再進行詳細的說明。 你可以用下面這樣的命令來向父進程發送信號： ``` kill -TERM `cat /usr/local/apache2/logs/httpd.pid` ``` 第二種方法是使用下面將要描述的`httpd`二進制可執行文件的 `-k` 命令行選項：`stop`、`restart`、`graceful`、`graceful-stop` 。不過我們推薦你使用`apachectl`控制腳本來向`httpd`二進制可執行文件傳遞這些選項。 當你向`httpd`發送信號后，你可以這樣來讀取它的進行過程： ``` tail -f /usr/local/apache2/logs/error_log ``` 你可以修改這些示例以適應你的`ServerRoot`和`PidFile`設置。 ## 立即停止 信號：TERM `apachectl -k stop` 發送`TERM`或`stop`信號到父進程可以使它立刻殺死所有子進程。這將花費一些時間來殺死所有子進程。然后父進程自己也退出。所有進行中的請求將被強行中止，而且不再接受其它請求。 ## 優雅重啟 信號：USR1 `apachectl -k graceful` `USR1`或`graceful`信號使得父進程_建議_子進程在完成它們現在的請求后退出(如果他們沒有進行服務，將會立刻退出)。父進程_重新讀入_配置文件并重新打開日志文件。每當一個子進程死掉，父進程立刻用新的配置文件產生一個新的子進程并立刻開始伺服新的請求。 重啟代碼的設計能夠確保MPM進程控制指令的正常運作，也就是在重啟過程中確保有適當數量的進程和線程以響應客戶端的請求。它是這樣`StartServers`的：如果在一秒鐘以后還沒有新創建`StartServers`個子進程，則創建出足夠完成現在任務的子進程個數。因此，代碼除了保有能夠維持服務器的現有負載數量的子進程外，也確保`StartServers`按你的意愿運作。 使用`mod_status`的用戶會注意到在`USR1`信號發出后，服務器的統計信息**沒有**被清零。代碼被寫成既能將你服務器無法伺服新請求的時間降至最少(這些請求將被操作系統放到隊列里，使得它們不會丟失)，又能遵從你的參數優化。為了做到這一點，它將在重新生成子進程的過程中，在_scoreboard_上保存所有子進程的狀態。 `mod_status`還會將那些在優雅重啟前就已經開始而沒有結束伺服請求的子進程用一個"`G`"來標志。 目前，日志滾動腳本還無法使用`USR1`來確定所有寫入預重啟日志的子進程都已結束。我們建議你在發出了`USR1`信號后等待一個適當的時間，然后再對舊的日志做處理。比如說如果對于一個窄帶用戶來說，大部分的點擊處理將在10分鐘之內完成，那么你應該在處理舊的日志前等待15分鐘。 如果Apache重啟時發現配置文件有誤，那么父進程將不會重啟，而是報錯并退出。在優雅重啟的情況下，它將在處理中的子進程存在的情況下維持它的存在(就是那些被要求在處理完它們的請求后"優雅退出"的子進程)。如果你要重啟服務器，這將導致一些問題：它將不能綁定到它的監聽端口。在執行重啟之前，你可以用 `-t` 命令行參數來檢查配置文件語法的正確性(參見`httpd`)。但這仍然不能保證服務器一定可以正確的重啟。為了從語法和語義兩方面檢查配置文件，你可以用一個非root用戶來啟動`httpd`。如果沒有錯誤，它將嘗試去打開套接字和日志文件，繼而因沒有root權限而失敗(或是因為現在運行的`httpd`已經綁定了這些端口)。如果是因為其他原因那么就可能是一個配置文件產生的錯誤，你就應當在進行優雅重啟之前改正這個錯誤。 ## 立即重啟 信號：HUP `apachectl -k restart` 向父進程發送`HUP`或`restart`信號會使它象收到`TERM`信號一樣殺掉所有的子進程，不同之處在于父進程本身并不退出。它重新讀入配置文件、重新打開日志文件。然后產生一系列新的子進程來繼續服務。 使用`mod_status`的用戶會注意到在`HUP`信號發出后，服務器統計信息會被清零。 如果你重啟時配置文件有誤，那么父進程將不會重啟，而是報錯并退出。參見上文中避免的方法。 ## 優雅停止 信號：WINCH `apachectl -k graceful-stop` `WINCH`或`graceful-stop`信號使得父進程_建議_子進程在完成它們現在的請求后退出(如果他們沒有進行服務，將會立刻退出)。然后父進程刪除`PidFile`并停止在所有端口上的監聽。父進程仍然繼續運行并監視正在處理請求的子進程，一旦所有子進程完成任務并退出或者超過由`GracefulShutdownTimeout`指令規定的時間，父進程將會退出。在超時的情況下，所有子進程都將接收到`TERM`信號并被強制退出。 在"優雅"狀態下，`TERM`信號將會立即中止父進程和所有子進程。由于`PidFile`已經被刪除，你將無法使用`apachectl`或`httpd`發送該信號。 ``` graceful-stop允許你同時運行多個相同配置的[httpd](#calibre_link-54)實例。這在對Apache進行平滑升級的時候是一個非常有用的特性。不過它在某些配置的情況下同樣可能會導致死鎖和競爭條件。 必須注意確保諸如`Lockfile`和`ScriptSock`之類的磁盤文件包含服務器的PID ，并且能夠安全的共存。然而如果一個配置指令、第三方模塊或持久CGI使用任何磁盤鎖或狀態文件，必須注意確保多個`httpd`運行實例之間不會爭搶文件。 你還必須防止潛在的競爭條件，比如使用`rotatelogs`風格的管道日志。運行中的多個`rotatelogs`實例企圖同時滾動同一個日志文件可能會導致互相破壞對方的日志文件。 ``` ## 附錄：信號和競爭條件 在Apache 1.2b9 之前，有很多關于重啟和死亡信號的_競爭條件。_關于競爭條件的一個簡單描述是：一個時間敏感的問題，如果一些事情在不適當的時間或以不恰當的順序發生，它將作出你不期望的反應；如果同樣的事情在恰當的時間發生，則不會出現異常。憑借那些擁有"正確"特性設置的體系結構，我們盡量避免了它們的出現。但值得注意的是，仍然有一些競爭條件存在于這樣的體系結構中。 使用物理磁盤的`ScoreBoardFile`就有損壞ScoreBoard的潛在危險。這將發生在"bind: Address already in use"(`HUP`之后)或"long lost child came home!"(`USR1`之后)時。前者是一個致命錯誤，而后者則會使服務器丟失ScoreBoard的一個記錄。所以我們建議多使用優雅重啟，偶爾使用硬重啟。這些問題很難解決，但幸運的是大多數結構并不需要ScoreBoard文件。而如果你需要這樣的結構，你可以參考`ScoreBoardFile`文檔。 當每個子進程在一個HTTP的持續連接(KeepAlive)中涉及到第二個并發的請求時，所有的結構都會或多或少存在競爭狀態的問題。它將在讀取了請求而沒有讀取任何請求頭之后立刻退出。這個修復對于1.2來說來得太晚了。但因為持續連接的客戶端已經考慮到網絡延時和服務器超時會造成類似的情況，所以理論上說，這不是一個太大的問題。而實際上似乎也沒有任何影響：在一個測試案例中服務器在一秒之內被重啟了20次，而客戶端卻成功的瀏覽了網站，而且沒有任何破損的圖片或空文檔。