Konfiguracja Nginx przeładowuje się bez przestoju

122

Używam nginx jako odwrotnego proxy. Ilekroć aktualizuję konfigurację dla niego za pomocą

sudo "cp -r #{nginx_config_path}* /etc/nginx/sites-enabled/"
sudo "kill -s HUP `cat /var/run/nginx.pid`"

Mam do czynienia z krótkim przestojem. Jak mogę tego uniknąć?

nginx

— Saurav Shah
źródło

1

Czy mają to być polecenia wiersza poleceń? Nigdy nie widziałem, żeby ktoś zawijał całe polecenie sudo w takich cytatach, może to nie być konieczne.

— brianmearns

4

Tylko ogólny komentarz: myślę, że standardową / zalecaną praktyką jest utworzenie miękkiego / symbolicznego linku do konfiguracji witryny pod sites-enabled, a nie kopiowanie go. Nie ma związku z konkretnym problemem, ale możesz przyjrzeć się temu.

— brianmearns 12.04.16

1

Nie powinieneś mieć przestoju. kill HUPjest sposobem na płynne przeładowanie w Nginx.

— Jonathan Vanasco

181

Uruchom service nginx reloadlub/etc/init.d/nginx reload

Wykona gorący przeładowanie konfiguracji bez przestojów. Jeśli masz oczekujące żądania, będą istnieć długotrwałe procesy nginx, które będą obsługiwać te połączenia przed ich śmiercią, więc jest to niezwykle wdzięczny sposób na ponowne załadowanie konfiguracji.

Czasami możesz chcieć nadrobić zaległości sudo

— Hengjie
źródło

10

Oba powinny robić dokładnie to, co mówi pytanie: wysłać SIGHUPdo głównego procesu nginx. Nie powinno być różnicy. nginx.org/en/docs/control.html

— Gnarfoz

Kiedy wydajemy komendę na CentOS, ciągle mówi „Użycie /etc/init.d/nginx (start..stop ... restart..reload)”… i właśnie tak go użyłem. W pliku /init.d/nginx znalazłem kill -HUP cat $PIDFILE|| echo -n „nie można przeładować”

— mashup

1

czy wiesz, jaka jest różnica między service nginx reloadi nginx -s reload? Jeśli uruchomię ten pierwszy, otrzymam ten wynik:, Reloading nginx configuration: nginx.ale moje zmiany nie zostaną zaktualizowane. Jeśli uruchomię to drugie, nie otrzymam danych wyjściowych, ale moje zmiany zostaną odzwierciedlone.

— Ryan Quinn

Właśnie próbowałem tego po dodaniu log_not_founddyrektywy, ale stwierdziłem, że musiałem zrestartować komputer, aby go uruchomić. Myślę, że przeładowanie nie działa dla wszystkich dyrektyw?

— mydoghasworms

81

Biegać /usr/sbin/nginx -s reload

Zobacz http://wiki.nginx.org/CommandLine, aby uzyskać więcej opcji wiersza poleceń.

— Shiv Kumar Sah
źródło

Wreszcie polecenie, które działa w Debian Jessie.

— niebezpieczne89

1

To lepszy sposób. Ponieważ serwer nie działa , jeśli konfiguracje zawierają błędy (w tym przypadku pokazuje tylko błędy).

— Mir-Ismaili,

jeśli domyślny pgin nginx nie znajduje się w domyślnej lokalizacji, potrzebujesz '-p'. tj .: `/ opt / gitlab / embedded / sbin / nginx -s reload -p / var / opt / gitlab / nginx`

— qxo

9

Nie, jesteś niepoprawny, nie powinieneś spotykać się z żadnymi przestojami dzięki opisanej procedurze. (Nginx może nie tylko przeładowywać konfigurację w locie bez żadnych przestojów, ale nawet aktualizować plik wykonywalny w locie, wciąż bez żadnych przestojów).

Zgodnie z http://nginx.org/docs/control.html#reconfiguration , wysłanie HUPsygnału do nginx upewnia się, że wykonuje płynne ponowne uruchomienie, a jeśli pliki konfiguracyjne są niepoprawne, cała procedura jest przerywana, a ty ' pozostało z nginx jak przed wysłaniem HUPsygnału. W żadnym momencie nie powinno być żadnych przestojów.

Aby nginx ponownie odczytał plik konfiguracyjny, sygnał HUP powinien zostać wysłany do procesu głównego. Proces główny najpierw sprawdza poprawność składni, a następnie próbuje zastosować nową konfigurację, czyli otworzyć pliki dziennika i nowe gniazda nasłuchiwania. Jeśli to się nie powiedzie, wycofuje zmiany i kontynuuje pracę ze starą konfiguracją.

— cnst
źródło

2

Zwykle ponowne ładowanie pliku konfiguracyjnego usługi nie powinno wpływać na działającą usługę. Zależy to jednak od sposobu SIGHUPprzetwarzania sygnału.

Jeśli określona usługa ma przestój podczas ponownego ładowania, można to obejść, uruchamiając tę samą usługę na wielu serwerach, najlepiej za pomocą modułu równoważenia obciążenia. W takim przypadku możesz wyjąć jeden serwer na raz i ponownie go załadować / zrestartować. Następnie można go ponownie dodać po potwierdzeniu, że jest OK.

— Khaled
źródło

Chociaż nie odpowiada to bezpośrednio na pytanie, jest to z pewnością scenariusz najlepszych praktyk, który PO mądrze byłoby zastosować, aby uniknąć przestojów w ogóle.

— Andrew M.,

1

Szczegółowe informacje o tym, jak nginx obsługuje różne sygnały: nginx.org/en/docs/control.html

— Gnarfoz