轉載自：https://www.cnblogs.com/zjzhuwenbo/archive/2013/12/12/3471231.html
Apache是怎樣啓動的
如果配置文件中Listen定義的是默認的80端口(或1024以下)，那麼啓動Apache將 需要root權限以將它綁定在特權端口上。一旦服務器開始啓動並完成了一些諸如打開日誌文件之類的準備操作，它將創建很多子進程來完成一些諸如偵聽和迴應 客戶端請求的工作。httpd主進程仍然以root用戶的權限運行，而它的子進程將以一個較低權限的用戶運行。這將由你選擇的多路處理模塊進行控制。
調用httpd可執行文件的推薦方法是使用apachectl控制腳本。此腳本設置了在某些操作系統中正常運行httpd所必需的環境變量，然後調用 httpd二進制文件。apachectl會傳遞命令行的所有參數，因此所有用於httpd的選項多半也可以用於apachectl 。你可以直接修改apachectl腳本，改變首部的HTTPD變量使之指向httpd可執行文件的正確位置，也可以設置任意的命令行參數，使之總是有 效。
httpd被調用後第一件要做的事情就是找到並讀取配置文件httpd.conf 。此文件的位置是在編譯時設定的，但也可以象下面這樣在運行時用 -f 選項來指定：
/usr/local/apache2/bin/apachectl -f /usr/local/apache2/conf/httpd.conf
如果啓動過程一切正常，服務器將與終端分離並幾乎立即出現命令行提示符。這表示服務器已經啓動並開始運行。然後你就可以用你的瀏覽器去連接你的服務器來查看DocumentRoot目錄下的測試文檔及其頁面鏈接裏的其它文檔的本地副本。
啓動時發生錯誤
如果Apache在啓動過程中發生了致命錯誤，它將在退出前把描述這個錯誤的信息顯示在終端上或者寫入到ErrorLog中。一個最常產生的錯誤信息是"Unable to bind to Port ..."，這主要由以下原因造成：
想由一個特權端口啓動服務但沒有以root用戶運行
啓動服務時已經有另外的Apache實例在運行或其他的web服務器已經綁定了同樣的端口
更多問題的解決辦法，請參見常見問題。
隨系統啓動時啓動
如果你希望你的服務器在系統重啓後仍保持運行狀態，你應該把apachectl的調用加入到你的系統啓動文件中(通常爲rc.local文件或rc.N目 錄下的某一文件)。這將會以root權限啓動Apache。當然，在此之前，你必須保證你的服務器已經完成了安全和訪問權限的設定。
apachectl腳本被設計爲可以用作SysV初始化腳本，它接受start、restart、stop參數，並把它們翻譯爲httpd對應的信號，所以通常都可以將apachectl連接到適當的初始目錄，但是需要檢查你的系統對此的精確要求。
額外信息
關於httpd和apachectl以及其他相關支持程序的命令行選項的詳細信息請參見服務器和支持程序頁面。其中還包括所有的隨Apache發行包發佈的模塊和它們提供的指令的文檔
停止和重啓簡介簡介
爲了停止或者重新啓動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實例。這在對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次，而客戶端卻成功的瀏覽了網站，而且沒有任 何破損的圖片或空文檔 。