डाउनटाइम के बिना नग्नेक्स कॉन्फ़िगरेशन पुनः लोड करें

122

मैं nginx को एक रिवर्स प्रॉक्सी के रूप में उपयोग करता हूं। जब भी मैं इसका उपयोग करके इसके लिए कॉन्फ़िगर को अपडेट करता हूं

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

मैं एक संक्षिप्त समय का सामना करता हूं। मैं इससे कैसे बच सकता हूं?

nginx

— सौरव शाह
स्रोत

1

क्या वे कमांड लाइन कमांड होने के लिए हैं? मैंने कभी किसी को पूरे सूडो कमांड को इस तरह उद्धरणों में लपेटते नहीं देखा, यह आवश्यक नहीं हो सकता है।

— ब्रायनमर्न्स

4

बस एक सामान्य टिप्पणी: मुझे लगता है कि मानक / अनुशंसित अभ्यास आपकी साइट कॉन्फ़िगरेशन के लिए एक नरम / प्रतीकात्मक लिंक के तहत बनाता है sites-enabled, इसे कॉपी नहीं करता है। आपके विशेष मुद्दे से संबंधित नहीं है, लेकिन आप उस पर गौर करना चाहते हैं।

— ब्रायनमर्न्स

1

आपको डाउनटाइम का सामना नहीं करना चाहिए। kill HUPnginx में एक सुंदर रीलोड करने का तरीका है।

— जोनाथन वानास्को

181

भागो service nginx reloadया/etc/init.d/nginx reload

यह डाउनटाइम के बिना कॉन्फ़िगरेशन का एक गर्म पुनः लोड करेगा। यदि आपके पास लंबित अनुरोध हैं, तो निंगेरिंग प्रक्रियाएं होंगी जो मरने से पहले उन कनेक्शनों को संभालेंगी, इसलिए यह कॉन्फ़िगरेशन को फिर से लोड करने का एक बहुत ही सुंदर तरीका है।

कभी कभी आप के साथ प्रस्तुत करना चाहते हो सकता है sudo

— Hengjie
स्रोत

10

उन दोनों को बिल्कुल वही करना चाहिए जो सवाल कहता है: SIGHUPनगनेक्स मास्टर प्रक्रिया को भेजें । अंतर नहीं होना चाहिए। nginx.org/en/docs/control.html

— Gnarfoz

जब मैं CentOS पर कमांड जारी करता हूं तो यह कहता है कि "Use /etc/init.d/nginx (start..stop ... restart..reload)" .. और ठीक इसी तरह मैंने इसका उपयोग किया। फ़ाइल के भीतर / init.d/nginx मैं मार पाया -HUP cat $PIDFILE|| इको-एन "रीलोड नहीं कर सकता"

— मैशप

1

क्या आप जानते हैं कि क्या अंतर है service nginx reloadऔर nginx -s reload? यदि मैं पूर्व चलाता हूं, तो मुझे यह आउटपुट मिलता है: Reloading nginx configuration: nginx.लेकिन मेरे परिवर्तन अपडेट नहीं हुए हैं। यदि मैं बाद को चलाता हूं, तो मुझे कोई आउटपुट नहीं मिलता है, लेकिन मेरे परिवर्तन प्रतिबिंबित होते हैं।

— रयान क्विन

मैंने सिर्फ एक log_not_foundनिर्देश जोड़ने के बाद यह कोशिश की लेकिन पाया कि मुझे वास्तव में इसे काम करने के लिए फिर से शुरू करना था। मुझे लगता है कि पुनः लोड करना सभी निर्देशों के लिए काम नहीं करता है?

— mydoghasworms

81

Daud /usr/sbin/nginx -s reload

अधिक कमांड लाइन विकल्पों के लिए http://wiki.nginx.org/CommandLine देखें ।

— शिव कुमार साह
स्रोत

अंत में, एक आदेश जो डेबियन जेसी में काम करता है।

— खतरे '

1

यह एक बेहतर तरीका है। क्योंकि आपके कॉन्फ़िगरेशन में त्रुटियां हैं (यदि इस मामले में केवल त्रुटियां दिखती हैं) तो आपका सर्वर डाउन नहीं होता है ।

— मीर-इस्माइली

यदि nginx डिफ़ॉल्ट डिफ़ॉल्ट डिफ़ॉल्ट स्थान पर नहीं है, तो '-p' की आवश्यकता है। यानी: `/ ऑप्ट / गिटलैब / एम्बेडेड / sbin / nginx -s पुनः लोड -p / var / ऑप्ट / gitlab / nginx`

— qxo

9

नहीं, आप गलत हैं, आप जिस प्रक्रिया का वर्णन करते हैं, उसके साथ आपको कोई डाउनटाइम सामना नहीं करना चाहिए। (नगनेक्स बिना किसी डाउनटाइम के न केवल मक्खी पर कॉन्फ़िगरेशन पुनः लोड कर सकता है, बल्कि यहां तक कि मक्खी पर निष्पादन योग्य का उन्नयन भी, फिर भी बिना किसी डाउनटाइम के।)

Http://nginx.org/docs/control.html#reconfiguration के अनुसार , HUPnginx को संकेत भेजना सुनिश्चित करता है कि यह एक सुंदर पुनरारंभ करता है, और, यदि कॉन्फ़िगरेशन फ़ाइलें गलत हैं, तो पूरी प्रक्रिया छोड़ दी जाती है, और आप आदि HUPसंकेत भेजने से पहले nginx के साथ छोड़ दिया । किसी भी बिंदु पर कोई डाउनटाइम संभव नहीं होना चाहिए।

कॉन्फ़िगरेशन फ़ाइल को फिर से पढ़ने के लिए nginx के लिए, मास्टर प्रक्रिया के लिए एक HUP संकेत भेजा जाना चाहिए। मास्टर प्रक्रिया पहले सिंटैक्स वैधता की जांच करती है, फिर लॉग फाइल खोलने और नए सुनने के सॉकेट के लिए नया कॉन्फ़िगरेशन लागू करने की कोशिश करती है। यदि यह विफल रहता है, तो यह वापस परिवर्तन करता है और पुराने कॉन्फ़िगरेशन के साथ काम करना जारी रखता है।

— CNST
स्रोत

2

आमतौर पर, किसी सेवा की कॉन्फ़िगरेशन फ़ाइल को लोड करने से रनिंग सेवा प्रभावित नहीं होनी चाहिए। हालांकि, यह इस बात पर निर्भर करता है कि SIGHUPसिग्नल को कैसे संसाधित किया जाता है।

यदि पुनः लोड के दौरान एक विशिष्ट सेवा डाउनटाइम का अनुभव कर रही है, तो इसे एक ही सेवा को कई सर्वरों पर अधिमानतः लोड बैलेंसर का उपयोग करके चलाया जा सकता है। इस स्थिति में, आप एक समय में एक सर्वर निकाल सकते हैं और इसे पुनः लोड / पुनः आरंभ कर सकते हैं। फिर, यह ठीक है की पुष्टि करने के बाद इसे फिर से जोड़ा जा सकता है।

— खालिद
स्रोत

हालांकि यह सीधे सवाल का जवाब नहीं देता है, लेकिन यह निश्चित रूप से एक सबसे अच्छा अभ्यास परिदृश्य है कि ओपी सामान्य रूप से डाउनटाइम से बचने के लिए पालन करने के लिए स्मार्ट होगा।

— एंड्रयू एम।

1

विवरण कैसे अलग-अलग संकेतों को संभालता है: nginx.org/en/docs/control.html

— Gnarfoz