Zatrzymywanie i ponowne uruchamianie serwera Apache HTTP
Graceful Restart
Signal: USR1 apachectl -k graceful
Sygnał USR1 lub graceful powoduje, że proces nadrzędny doradza dzieciom wyjście po ich bieżącym żądaniu (lub natychmiastowe zakończenie, jeśli „nic nie obsługują). Rodzic ponownie odczytuje swoje pliki konfiguracyjne i ponownie otwiera swoje pliki dziennika. Gdy każde dziecko umiera, rodzic zastępuje je dzieckiem z nowej generacji konfiguracji, które natychmiast rozpoczyna obsługę nowych żądań.
Ten kod jest zaprojektowany tak, aby zawsze przestrzegać dyrektywy MPM kontroli procesu, więc liczba procesów i wątków dostępnych do obsługi klientów będzie utrzymywana na odpowiednich wartościach przez cały proces restartu. Ponadto przestrzega StartServers w następujący sposób: jeśli po jednej sekundzie przynajmniej StartServers nowe dzieci nie zostały utworzone, a następnie stwórz wystarczająco dużo, aby zebrać luz. Dlatego kod stara się zachować zarówno liczbę elementów potomnych odpowiednią dla bieżącego obciążenia serwera, jak i uszanować Twoje życzenia za pomocą parametru StartServers.
Użytkownicy mod_status zauważy, że statystyki serwera nie są ustawione na zero po wysłaniu USR1. Kod został napisany tak, aby zarówno zminimalizować czas, w którym serwer nie jest w stanie obsłużyć nowych żądań (będą one ustawiane w kolejce przez system operacyjny, więc w żadnym wypadku nie zostaną utracone), jak i uszanować parametry strojenia. zrób to, aby tablica wyników służyła do śledzenia wszystkich dzieci z różnych pokoleń.
Moduł statusu użyje również G do wskazania tych dzieci, które są nadal obsługuje żądania rozpoczęte przed wdzięcznym ponownym uruchomieniem.
Obecnie nie ma możliwości, aby skrypt rotacji logów korzystający z USR1 wiedział na pewno, że wszystkie dzieci piszą dziennik przed ponownym uruchomieniem został zakończony. Sugerujemy użycie odpowiedniego opóźnienia po wysłaniu sygnału USR1, zanim zrobisz cokolwiek ze starym dziennikiem. Na przykład, jeśli większość trafień zajmuje mniej niż 10 minut dla użytkowników korzystających z łączy o niskiej przepustowości, możesz poczekać 15 minut, zanim zrobisz cokolwiek ze starym dziennikiem.
Po ponownym uruchomieniu najpierw uruchamiane jest sprawdzanie składni, aby upewnić się, że w plikach konfiguracyjnych nie ma błędów. Jeśli plik konfiguracyjny zawiera błędy, zostanie wyświetlony komunikat o błędzie dotyczący tego błędu składni, a serwer odmówi ponownego uruchomienia. Pozwala to uniknąć sytuacji, w której serwer zatrzymuje się, a następnie nie może ponownie uruchomić, pozostawiając niedziałający serwer.
To nadal nie gwarantuje, że serwer uruchomi się poprawnie. Aby sprawdzić semantykę plików konfiguracyjnych, a także składnię, możesz spróbować uruchomić httpd jako użytkownik inny niż root. Jeśli nie ma błędów, spróbuje otworzyć swoje gniazda i dzienniki, ale zakończy się niepowodzeniem, ponieważ nie jest on rootem (lub ponieważ aktualnie działający httpd ma już powiązane te porty). Jeśli to się nie powiedzie z jakiegokolwiek innego powodu jest to prawdopodobnie błąd pliku konfiguracyjnego i błąd powinien zostać naprawiony przed wykonaniem pełnego wdzięku restartu.