دوبارہ شروع کرنے کے بجائے دوبارہ لوڈ کریں
دوبارہ لوڈ کرنے سے NGINX کو ترتیب پھر سے پڑھنے کا کہا جاتا ہے۔ یہ نئے ورکر پروسیس شروع کرتا ہے اور پرانے پروسیس کو اپنی کھلی درخواستیں مکمل کرنے دیتا ہے، اس لیے عموماً صارفین کو کوئی فرق محسوس نہیں ہوتا۔ اگر نئی ترتیب نافذ نہ ہو سکے تو NGINX پرانی ترتیب کے ساتھ چلتا رہتا ہے۔ دوبارہ شروع کرنے میں پہلے سروس بند ہوتی ہے، اس لیے کنکشن منقطع ہوتے ہیں، اور ترتیب غلط ہو تو سروس دوبارہ شروع ہونے میں ناکام بھی ہو سکتی ہے۔
جس فائل کو بدل رہے ہیں اس کا بیک اپ لیں
تدوین سے پہلے فائل کے ساتھ ہی اس کی نقل بنائیں اور نقل کے نام میں تاریخ شامل کریں۔ ایسی ڈائریکٹری میں نقلیں نہ چھوڑیں جسے NGINX کسی وائلڈ کارڈ، مثلاً conf.d/*.conf یا sites-enabled/*، سے لوڈ کرتا ہو، کیونکہ وہ ان نقلوں کو بھی لوڈ کر لے گا۔ Debian اور Ubuntu پر sites-available میں موجود فائل کی تدوین کریں؛ sites-enabled میں موجود اندراج عموماً اسی کا لنک ہوتا ہے۔
sudo cp -a /etc/nginx/sites-available/example.conf /root/example.conf.$(date +%Y%m%d-%H%M%S)پہلے جانچیں، پھر دوبارہ لوڈ کریں
nginx -t ترتیب کی ساخت اور اس میں حوالہ دی گئی فائلوں، مثلاً سرٹیفکیٹس، کو جانچتا ہے۔ شامل کی گئی فائلوں کے بعد مکمل ترتیب دیکھنے کے لیے nginx -T استعمال کریں۔ صرف جانچ کامیاب ہونے پر دوبارہ لوڈ کریں؛ کمانڈز کو && سے جوڑنے سے یہ شرط پوری ہوتی ہے۔ یہ جانچ نہیں بتا سکتی کہ ترتیب آپ کے ارادے کے مطابق کام کرتی ہے یا نہیں، اس لیے بعد میں ویب سائٹ کھول کر دیکھیں۔
sudo nginx -t && sudo systemctl reload nginx
sudo nginx -T | less
curl -I https://example.com/جب کوئی خرابی ہو
بیک اپ والی نقل بحال کریں، دوبارہ جانچیں اور پھر دوبارہ لوڈ کریں۔ اگر سروس بند ہو گئی ہو تو خرابی کا لاگ اور جرنل وجہ بتاتے ہیں۔ ایسے پیغامات تلاش کریں جن میں پہلے سے زیر استعمال پورٹ، غائب سرٹیفکیٹ یا دہرائے گئے سرور نام کا ذکر ہو۔
sudo cp -a /root/example.conf.20261031-120000 /etc/nginx/sites-available/example.conf
sudo nginx -t && sudo systemctl reload nginx
sudo journalctl -u nginx -n 50 --no-pager
sudo tail -n 50 /var/log/nginx/error.logدوبارہ لوڈ کرنے کی حدود
WebSockets جیسے طویل مدت کے کنکشن ختم ہونے تک پرانے ورکرز کے ساتھ رہتے ہیں، اس لیے پرانے ورکرز کچھ دیر چلتے رہ سکتے ہیں اور اضافی میموری استعمال کر سکتے ہیں۔ کسی پیکیج کا اپ گریڈ خود بھی سروس دوبارہ شروع کر سکتا ہے۔ بڑی تبدیلیاں پہلے ٹیسٹ سرور پر آزمائیں، جن میں سرٹیفکیٹس اور ری ڈائریکٹس بھی شامل ہوں۔
CH-J Server Manager میں NGINX Manager
NGINX Manager، Linux سرورز پر زیر انتظام NGINX ڈائریکٹریوں میں ترتیب کی فائلوں کی تدوین کرتا ہے، ہر فائل کے لیے حد 512 KiB ہے۔ محفوظ کرتے وقت ایپلیکیشن .chj-backup- لاحقے کے ساتھ بیک اپ بناتی ہے، nginx -t چلاتی ہے اور صرف کامیاب جانچ کے بعد تبدیلی برقرار رکھتی ہے۔ دوبارہ لوڈ کرنے کے لیے آپ کی واضح تصدیق ضروری ہے اور شروع ہونے سے پہلے جانچ پھر چلائی جاتی ہے۔ فعال علامتی لنک تبدیل نہیں کیا جاتا؛ sites-available میں متعلقہ فائل کی تدوین کریں۔