1. 程式人生 > >apache2 啟動、重啟、停止方法

apache2 啟動、重啟、停止方法

Linux系統為Ubuntu 一、Start Apache 2 Server /啟動apache服務 
# /etc/init.d/apache2 start 
or 
$ sudo /etc/init.d/apache2 start 
二、 Restart Apache 2 Server /重啟apache服務 
# /etc/init.d/apache2 restart 
or 
$ sudo /etc/init.d/apache2 restart 
三、Stop Apache 2 Server /停止apache服務 
# /etc/init.d/apache2 stop 
or 
$ sudo /etc/init.d/apache2 stop 
linux下的apache 重啟和停止 

本文件敘述了在類Unix系統上如何停止和重啟Apache 。 Windows NT/2000/XP/2003的使用者請參見以服務方式執行Apache ,Windows 9x/ME使用者則參見在控制檯中執行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次,而客戶端卻成功的瀏覽了網站,而且沒有任何 破損的圖片或空文件。