🏅 👩‍💼 🚜 प्रक्रिया को फिर से शुरू किए बिना अपडेट किए गए resolv.conf से नए DNS सर्वर पते का उपयोग करने के लिए एक प्रक्रिया को मजबूर करने के लिए कैसे करें 🚋 ➖ 👨🏿‍🔧

मैं यूनिक्स सिस्टम प्रशासक के रूप में काम करता हूं। एक बार एक प्रोग्रामर का टिकट हेडर में एप्लिकेशन सर्वर लॉग से एक अंश के साथ हमारी सेवा रखरखाव विभाग में गिर गया: " pgbouncer सर्वर से कनेक्ट नहीं हो सकता "। Pgbouncers के लॉग को देखने के बाद, मैंने देखा कि हमारे DNS को एक्सेस करते समय समय-समय पर लुकअप विफलताएं आती हैं। यह पाया गया कि यह हमारे DNS सर्वरों के संचालन के कारण नहीं है, बल्कि स्वयं यूडीपी प्रोटोकॉल की अविश्वसनीयता के लिए: कभी-कभी पैकेट हानि विभिन्न कारणों से होती है।

नतीजतन, pgb बाउंसरों के साथ प्रत्येक सर्वर पर एक कैशिंग बंड स्थापित करने का निर्णय लिया गया। और यहाँ एक दिलचस्प समस्या उत्पन्न हुई: pgbouncer ने HUP सिग्नल पर /etc/resolv.conf फ़ाइल को फिर से नहीं पढ़ा और पुराने DNS सर्वरों का उपयोग जारी रखा। लेकिन आप स्पष्ट रूप से बाउंसरों को फिर से शुरू नहीं कर सकते हैं: ऐसी समस्याग्रस्त परियोजनाएं हैं जो डेटाबेस के साथ सत्र को तोड़ने के लिए बहुत संवेदनशील हैं।

इस लेख में मैं आपको बताऊंगा कि कैसे pgbouncer या कोई अन्य प्रोग्राम जो लाइब्रेरी कॉल getaddrinfo () का उपयोग करता है, को resolv.conf को फिर से पढ़ने और क्लाइंट के लिए पूरी तरह से दर्द रहित (बिना डाउनटाइम) नए DNS सर्वर का उपयोग शुरू करने के लिए मजबूर किया जा सकता है।

चलिए शुरू करते हैं

मुझे तुरंत कहना होगा कि मेरे मामले में pgbouncers के संस्करण 1.5.2 थे और FreeBSD के तहत libevent-1.4 के साथ बनाए गए थे।

यदि आप pgbouncer के स्रोत को देखते हैं, तो आप निम्न टिप्पणी को dnslookup.c फ़ाइल में देख सकते हैं:

/* * Available backends: * * udns - libudns * getaddrinfo_a - glibc only * libevent1 - returns TTL, ignores hosts file. * libevent2 - does not return TTL, uses hosts file. */

इसका मतलब यह है कि इस मामले में जब pgbouncer libevent1 के साथ बनाया गया है, तो मानक libc लाइब्रेरी से फ़ंक्शन getaddrinfo_a () अतुल्यकालिक पता रिज़ॉल्यूशन के लिए उपयोग किया जाता है।
अनुभवजन्य रूप से, यह पाया गया कि एसिंक्रोनस getaddrinfo_a () libc से सामान्य गेटड्रीनोफो () फ़ंक्शन का उपयोग करता है। हम अंतिम फ़ंक्शन पर एक ब्रेकपॉइंट सेट करेंगे। यह तथ्य हमें डिबगिंग प्रतीकों के साथ एक सार्वजनिक निर्माण करने से बचाता है, क्योंकि gdb getaddrinfo फ़ंक्शन को जानता है, इस तथ्य के बावजूद कि libc बिना डीबगिंग प्रतीकों के बनाया गया है।

एक गैर-मौजूद डेटाबेस से pgbouncer के कॉन्फ़िगर को जोड़ें जो एक गैर-मौजूद डोमेन (परीक्षण के लिए उपयोगी) को संदर्भित करता है:

 test = host=test.xaxa.blabla12313212.su user=pgsql dbname=template1 pool_size=10

एक अलग विंडो में, pgbouncer चलाएं:

 su -m pgbouncer -c '/usr/local/bin/pgbouncer /usr/local/etc/pgbouncer.ini'

एक अन्य विंडो में, gdb डीबगर का उपयोग करके प्रक्रिया से कनेक्ट करें:

 gdb /usr/local/bin/pgbouncer `cat /var/run/pgbouncer/pgbouncer.pid`

एक ब्रेकपॉइंट सेट करें और प्रक्रिया को और आगे बढ़ने दें:

 (gdb) b getaddrinfo Breakpoint 1 at 0x800f862a4 (gdb) c Continuing.

एक अन्य विंडो में, हम अपने डेटाबेस को गैर-मौजूद डोमेन के साथ जोड़ने का प्रयास करते हैं ताकि हल करने का प्रयास शुरू किया जा सके:

 su -m pgbouncer -c 'export PGPASSWORD="123" && /usr/local/bin/psql -Utest test -h10.9.9.16 -p6000';

जीडीबी में हम देखते हैं कि हमने बैल की आंख को मारा:

 Breakpoint 1, 0x0000000800f862a4 in getaddrinfo () from /lib/libc.so.7 (gdb)

Getaddrinfo () कैसे काम करता है?

मैनुअल और एक खोज इंजन का उपयोग करते हुए, यह पता चला कि यह फ़ंक्शन पहली कॉल पर resolv.conf फ़ाइल पढ़ता है, स्मृति में डेटा के एक गुच्छा के साथ एक संरचना को आरम्भ करता है, जिसके बीच आप DNS सर्वरों की एक सूची पा सकते हैं। अगला, फ़ंक्शन सूची में पहले पते का उपयोग करके पते को हल करने का प्रयास करता है। यदि DNS सर्वर प्रतिक्रिया नहीं देता है, तो फ़ंक्शन सूची से अगले DNS सर्वर को सक्रिय करता है। और इसलिए एक सर्कल में। फ़ंक्शन केवल एक बार resolv.conf पढ़ता है।

सबसे पहले, मैं pgbouncer की वर्चुअल मेमोरी को नेटवर्क ऑर्डर या होस्ट ऑर्डर फॉर्मेट में DNS सर्वर एड्रेस के 4 बाइट्स पाकर चाहता था। इसके लिए, सी मेमोरी प्रोग्राम भी लिखा गया था, जिसने प्रक्रिया मेमोरी को डंप करना और एक विशिष्ट बाइट ऑर्डर की खोज करना संभव बना दिया। लेकिन, जैसा कि यह निकला, स्मृति में इन पतों को इस रूप में खोजना असंभव है । Getaddinfo के स्रोत कोड को समझने के लिए () मेरी शक्ति से परे निकला: बहुत सारे पाठ और सभी प्रकार के गोटो ने मेरे दिमाग को लगभग तोड़ दिया। इसके अलावा, मैं एक प्रोग्रामर नहीं हूं, और सी ने एक महीने पहले ही सीखना शुरू किया।

वैसे, ptrace और procfs का उपयोग करने वाला मेरा कार्यक्रम libevent2 से निर्मित एक pgbouncer के लिए उपयुक्त होगा: वहाँ DNS सर्वरों के आईपी पते ठीक चार बाइट्स में संग्रहीत किए जाते हैं। लेकिन इस अनुभव का वर्णन लेख के दायरे से परे है।

क्या करें?

सौभाग्य से, एक खोज इंजन की मदद से, मुझे res_init () मानक पुस्तकालय में बचत कार्य मिला:

Res_init () नियमित कॉन्फ़िगरेशन फ़ाइल पढ़ता है (यदि कोई हो; देखें
डिफ़ॉल्ट डोमेन नाम, खोज सूची और इंटरनेट पाने के लिए रिज़ॉल्वर (5)
स्थानीय नाम सर्वर का पता

यह ऐसा फ़ंक्शन है जिसे पहली बार getaddrinfo () कहा जाता है और उस संरचना को आरंभ करता है जिसकी हमें ज़रूरत है!
फ़ंक्शन का बार-बार कॉल संरचना को फिर से संगठित करता है और resolv.conf को फिर से संगठित करता है।

चलिए जाँच करते हैं

ट्रैसर को हमारे "जमे हुए" pgbouncer से कनेक्ट करें और ट्रेस डंप फ़ाइल को grep शुरू करें:

 ktrace -f out.ktrace -p `cat /var/run/pgbouncer/pgbouncer.pid` kdump -l -f out.ktrace | grep resolv

Gdb के साथ विंडो में, हम res_init () फ़ंक्शन कहते हैं:

 (gdb) call res_init() Breakpoint 1, 0x0000000800f862a4 in getaddrinfo () from /lib/libc.so.7

ट्रेस परिणाम के आउटपुट के साथ विंडो में, हम देखते हैं:

 37933 pgbouncer NAMI "/etc/resolv.conf"

लक्ष्य हासिल किया

हम सर्वर को छोड़ने या सक्रिय tcp राज्यों को तोड़ने के बिना, resolv.conf को फिर से पढ़ने के लिए प्रक्रिया प्राप्त करने में कामयाब रहे। ठंड के समय, अनुरोध भी खो नहीं जाते हैं।

यदि हम चाहते हैं कि स्थानीय कैशिंग डीएनएस का तुरंत उपयोग किया जाए, तो हमें निम्नलिखित कदम उठाने होंगे:

BIND फ़ॉर्वर्डर्स में, सर्वरों को नए (अन्य) वर्किंग डीएनएस सर्वरों में बदलें जो कि पहले resolv.conf में उपयोग नहीं किए गए थे और उनका उपयोग नहीं किया जाएगा, और फिर रेंडक पुनः लोड करें
पुराने DNS सर्वर तक पहुँचने से स्थानीय फ़ायरवॉल को प्रतिबंधित करें (127.0.0.1 को छोड़कर)
एक गैर-मौजूद डेटाबेस सर्वर में एक pgbouncer'a कॉल आरंभ करें:
```
 su -m pgbouncer -c 'export PGPASSWORD="123" && /usr/local/bin/psql -Utest test -h127.0.0.1 -p6000'; 
```
Tcpdump के साथ सत्यापित करें कि pgbouncer पोर्ट 53 पर 127.0.0.1 तक पहुँच रहा है:
```
 tcpdump -n -i lo0 port 53 | grep xaxa "> 127.0.0.1.53" - 
```
जहाँ xaxa pgbouncer.conf से सर्वर नाम का हिस्सा है
फ़ायरवॉल में पुराने DNS को अनमास्क करें
अपनी मूल स्थिति में फ़ॉरवर्डर्स सेटिंग को रीसेट करें

और आखिरी

यदि आप मेरे अनुभव को दोहराना चाहते हैं, तो मैं एक परीक्षण बेंच पर प्रशिक्षण की सिफारिश करता हूं।
यदि आप बैच मोड में जीडीबी में एक कमांड "बुलेट" करना चाहते हैं, तो ध्यान रखें कि जीडीबी को पहले पात्रों को पढ़ने के लिए समय दिया जाना चाहिए, और फिर फ़ंक्शन को बुलाया जाना चाहिए: मैंने किसी तरह 8-8 में से एक को मारकर इसे खराब कर दिया। मील काम कर रहे pgbouncers।
जीडीबी के लिए बैच मोड अब इस तरह से चलता है:

 printf 'shell sleep 3\ncall res_init()\ndetach\nquit\n' > /tmp/pb.gdb && gdb -batch -x /tmp/pb.gdb /usr/local/bin/pgbouncer `cat /var/run/pgbouncer/test.pid`

मुझे उम्मीद है कि मेरा अनुभव किसी को यह समझने में मदद करेगा कि ऑपरेटिंग सिस्टम में प्रक्रियाएं कैसे काम करती हैं।