Zatrzymywanie i uruchamianie Apache'a

Powinieneś zaobserwować uruchomionych wiele procesów httpd w Twoim systemie, ale nie powinieneś wysyałać żadnych sygnałów sterujących do nich z wyjątkiem procesu parent, którego pid zapisany jest w PidFile. Wynika z tego, że nie powinieneś potrzebować wysyłać żadnych sygnałów do jakiegokolwiek procesu z wyjątkiem procesu parent. Są trzy sygnały które możesz wysłać do procesu parent: TERM, HUP, i USR1, które zostaną za chwilę opisane. Aby wysłać sygnał do procesu parent powinieneś wydać komendę:

    kill -TERM `cat /usr/local/etc/httpd/logs/httpd.pid`

    tail -f /usr/local/etc/httpd/logs/error_log

TERM Signal: stop now

Wysyłanie sygnału TERM do procesu parent powoduje natychamistową próbę zatrzymania wszystkich własnych procesów children. Może to zająć kilka sekund aby zatrzymać wszystkie własne procesy children. Następnie proces parent zatrzymuje sam siebie. Wszystkie prośby połączenia w czasie zatrzymywania i potem są odrzucane.

HUP Signal: restart now

Wysyłanie sygnału HUP do procesu parent powoduje zatrzymanie procesów children podobnie jak sygnał TERM ale nie zatrzymuje samego procesu parent. Następuje ponowne odczytanie plików konfiguracyjnych, otwarcie logów, uruchomienie nowych procesów children i kontynuacja pracy serwera.

Użytkownicy modułu status module powninni zaobserwować że statystyka serwera zostaje wyzerowana, kiedy zostanie wysłany sygnał HUP.

Uwaga:Jeżeli Twoje pliki konfiguracyjne zawierają błędy i wydasz polecenie zrestartowania Twój proces parent nie zrestartuje się i zakończy błędnie pracę. Zobacz niżej metodę która zapobiega temu.

USR1 Signal: graceful restart

Uwaga: Do wersji 1.2b9 ten kod jest w miarę niestabilny i nie powinien być używany w całości.

Sygnał USR1 powoduje, że proces parent zawiadamia proces children aby zakończyl pracę po skończeniu odpowiadania na prośby połączeń (lub do natychmiastowego zakończenia pracy jeżeli dany proces nie serwuje żadnej usługi). Proces parent odczytuje ponownie pliki konfiguracyjne i otwiera logi. Jeżeli jeden z procesów child zakończy pracę, proces parent uruchomi nowy proces child w miejsce poprzedniego. Nowy proces child rozpoczyna pracę natychmiast po wywołaniu go.

Kod ten jest zaprojektowany aby zawsze zwracał uwagę na ustawienia MaxClients, MinSpareServers, i MaxSpareServers. Idąc dalej, kod ten zwraca uwagę na StartServers w następujący sposób: Jeżeli po jednej sekundzie nie będzie utworzony choćby jeden proces children kod utworzy wystarczającą ilość procesów do zlikwidowania zastoju w pracy serwera. Można powiedzieć, że kod ten próbuje utrzymać odpowiednią liczbę procesów children stosowną do aktualnego obciążenia serwera.

Użytkownicy modułu status module powinni zaobserwować, że statystyka sewera nie zostaje wyzerowana podczas wysłania sygnału USR1. Kod ten został napisany aby zminimalizować czas w którym serwer nie jest aktywny i nie odpowiada na żądania połączeń (połączenia powinny być kolejkowane przez system, także nie powinny nigdzie zaginąć) a także żeby respektował Twoje polecenia które mają usprawnić działanie serwera. W czasie wykonywania kodu, utrzymywany jest scoreboard wykorzystywany do utrzymania ścieżek między wszystkimi procesami children.

Moduł status module wykorzystuje również G do wskazywania procesów children, które nadal serwują prośby połączeń przed podaniem sygnału graceful restart.

Obecnie nie ma możliwości rotacji logów używając USR1 aby być pewnym, że wszystkie procesy zakończyły zapisywanie do logów proponujemy ustawić odpowiednie opóźnienie po wysłaniu sygnału USR1 przed przystąpieniem do robienia czegokolwiek ze starymi logami. Na przykład jeżeli większość z Twoich zadań zabiera mniej niż 10 minut do zakończenia przesyłania danych użytkownikom mających wolne łącze, możesz poczekać 15 minut zanim będziesz robił cokolwiek ze starymi logami.

Uwaga:Jeżeli Twoje pliki konfiguracyjne zawierają błędy i wydasz polecenie restartowania wtedy Twój proces parent nie zrestatuje się, zakończy błędnie działanie. W przypadku graceful restart zostawi działające procesy children a sam zakończy pracę. (Procesy te zakończą pracę po zakończeniu aktualnego połączenia.) To stworzy problem, jeżeli będziesz chciał zrestartować serwer -- nie będzie można powiązać portów na których były prowadzone nasłuchiwania. Aby temu zapobiec obecnie jedyną możliwością jest sprawdzenie składni swoich plików przed zrestartowaniem. Łatwiejszym sposobem jest uruchomienie httpd jako zwykły użytkownik. Jeżeli nie będzie błędów, httpd spróbuje otworzyć socket'y oraz logi. W tym momencie nie uda mu się to ponieważ nie ma praw administratora (lub działający w tym samym czasie inny httpd wykorzystuje już te porty). Jeżeli nie uda się to z jakiegokolwiek innego powodu oznacza to prawdopodobnie błąd pliku konfiguracyjnego. Błąd ten powinien zostać poprawiony przed ponownym restartem.

Dodatek: signals and race conditions

Wersje Apache'a do 1.2b9 miały kilka race condidions komplikujących restartowanie i "umieranie" sygnałów (prosty opis race condidion : problem wrażliwości na czas, jeżeli wydarzyło się coś w nie właściwym czasie, lub zachowało sie nie tak jak zostało to przewidziane). Dla tych systemów gdzie mieliśmy prawo modyfikacji wyeliminowaliśmy tak dużo jak tylko to możliwe. Ale mimo to problem race conditions z pewnością istnieje.

Systemy, które używają na dysku ScoreBoardFile mogą potencjalnie uszkadzać własne scoreboard'y. Coś takiego może pojawić się gdy adres jest już w użyciu (po sygnale HUP) lub po dłuższej utracie procesu child (po sygnale USR1). Pierwszy z dwóch wymienionych błędów jest nieunikniony, po chwili powoduje, że serwer traci scoreboard slot. Zatem wskazane jest restartowanie serwera w trybie graceful (łagodnym) czasami potrzebny jest "twardy" restart. Błędy te są uciążliwe przy ciągłej pracy, ale na szczęście większość systemów nie wymaga pliku scoreboard. Zajrzyj do dokumentacji ScoreBoardFile aby poznać metodę, która określa czy Twój system wykorzystuje ScoreBoard'y.

NEXT i MACHTEN (tylko dla procesorów 68k) mają małe race conditions, które mogą powodować restartowanie/"umieranie" sygnałów ale nie powinno być to przyczyną innych problemów z serwerem.

Wszystkie systemy posiadają niewielkie race conditions, każdy proces child pociąga za sobą coraz to kolejne żądania połączeń do procesu HTTP (KeepAlive). Proces ten może zakończyć działanie po odpowiedzi na żądanie połączenia ale przed przeczytaniem nagłówków. Istnieje rozwiązanie tego problemu, ale zostało odkryte zbyt późno aby zostało załączone do wersji 1.2. Teoretycznie nie powinno to przeszkadzać ponieważ klienci KeepAlive i tak oczekują takich zdarzeń spowodowanymi timeout'ami w sieci. W praktyce wygląda na to że na nic to nie ma wpływu -- podczas testu serwer był restartowany dwadzieścia razy na sekundę a klientom z powodzeniem wyświetlały się dokumenty, bez jakichkolwiek błędów.