گوگل کلاؤڈ تکنیکی مدد سے غائب DNS پیکٹ کے بارے میں ایک کہانی

گوگل بلاگ ایڈیٹر سے: کیا آپ نے کبھی سوچا ہے کہ گوگل کلاؤڈ ٹیکنیکل سلوشنز (TSE) انجینئرز آپ کی سپورٹ کی درخواستوں کو کیسے ہینڈل کرتے ہیں؟ TSE ٹیکنیکل سپورٹ انجینئرز صارف کی طرف سے رپورٹ کردہ مسائل کے ذرائع کی شناخت اور درست کرنے کے ذمہ دار ہیں۔ ان میں سے کچھ مسائل کافی آسان ہیں، لیکن بعض اوقات آپ کو ایک ٹکٹ مل جاتا ہے جس پر ایک ساتھ کئی انجینئرز کی توجہ درکار ہوتی ہے۔ اس مضمون میں، TSE کا ایک ملازم ہمیں اپنی حالیہ مشق سے ایک بہت ہی مشکل مسئلے کے بارے میں بتائے گا۔ DNS پیکٹ غائب ہونے کا معاملہ. اس کہانی میں، ہم دیکھیں گے کہ انجینئرز نے صورتحال کو کیسے حل کیا، اور غلطی کو ٹھیک کرتے ہوئے انہوں نے کون سی نئی چیزیں سیکھیں۔ ہم امید کرتے ہیں کہ یہ کہانی نہ صرف آپ کو ایک گہرے مسئلے کے بارے میں آگاہ کرے گی، بلکہ آپ کو Google Cloud کے ساتھ سپورٹ ٹکٹ فائل کرنے کے عمل کے بارے میں بھی بصیرت فراہم کرے گی۔

خرابی کا سراغ لگانا ایک سائنس اور فن دونوں ہے۔ یہ سب نظام کے غیر معیاری رویے کی وجہ کے بارے میں ایک مفروضے کی تعمیر کے ساتھ شروع ہوتا ہے، جس کے بعد اس کی طاقت کی جانچ کی جاتی ہے۔ تاہم، اس سے پہلے کہ ہم کوئی مفروضہ تشکیل دیں، ہمیں مسئلہ کو واضح طور پر بیان کرنا اور درست طریقے سے وضع کرنا چاہیے۔ اگر سوال بہت مبہم لگتا ہے، تو آپ کو ہر چیز کا بغور تجزیہ کرنا پڑے گا۔ یہ مسئلہ حل کرنے کا "فن" ہے۔

گوگل کلاؤڈ کے تحت، اس طرح کے عمل تیزی سے پیچیدہ ہو جاتے ہیں، کیونکہ گوگل کلاؤڈ اپنے صارفین کی رازداری کی ضمانت دینے کی پوری کوشش کرتا ہے۔ اس کی وجہ سے، TSE انجینئرز کو آپ کے سسٹمز میں ترمیم کرنے تک رسائی نہیں ہے، اور نہ ہی کنفیگریشنز کو صارفین کی طرح وسیع پیمانے پر دیکھنے کی صلاحیت ہے۔ لہٰذا، ہمارے کسی بھی مفروضے کو جانچنے کے لیے، ہم (انجینئر) نظام میں فوری ترمیم نہیں کر سکتے۔

کچھ صارفین کا خیال ہے کہ ہم کار سروس میں میکینکس کی طرح ہر چیز کو ٹھیک کر دیں گے، اور ہمیں صرف ایک ورچوئل مشین کی آئی ڈی بھیجیں گے، جبکہ حقیقت میں یہ عمل گفتگو کی شکل میں ہوتا ہے: معلومات جمع کرنا، مفروضوں کی تشکیل اور تصدیق (یا تردید)، اور، آخر میں، فیصلے کے مسائل کلائنٹ کے ساتھ بات چیت پر مبنی ہوتے ہیں۔

سوال میں مسئلہ

آج ہمارے پاس ایک اچھے اختتام کے ساتھ ایک کہانی ہے۔ مجوزہ کیس کے کامیاب حل کی ایک وجہ اس مسئلے کی بہت تفصیلی اور درست وضاحت ہے۔ ذیل میں آپ پہلے ٹکٹ کی ایک کاپی دیکھ سکتے ہیں (خفیہ معلومات کو چھپانے کے لیے ترمیم کی گئی):

اس پیغام میں ہمارے لیے بہت سی مفید معلومات ہیں:

• مخصوص VM بیان کیا گیا۔
• مسئلہ خود اشارہ ہے - DNS کام نہیں کرتا ہے۔
• یہ اشارہ کیا جاتا ہے جہاں مسئلہ خود کو ظاہر کرتا ہے - VM اور کنٹینر
• صارف نے مسئلہ کی نشاندہی کرنے کے لیے جو اقدامات کیے ان کی نشاندہی کی گئی ہے۔

درخواست کو "P1: Critical Impact - Service unusable in Production" کے طور پر رجسٹر کیا گیا تھا، جس کا مطلب ہے "Follow the Sun" اسکیم کے مطابق 24/7 صورت حال کی مسلسل نگرانی (آپ اس کے بارے میں مزید پڑھ سکتے ہیں۔ صارف کی درخواستوں کی ترجیحات)، ہر ٹائم زون شفٹ کے ساتھ ایک ٹیکنیکل سپورٹ ٹیم سے دوسری میں منتقلی کے ساتھ۔ درحقیقت، جب تک مسئلہ زیورخ میں ہماری ٹیم تک پہنچا، اس نے پوری دنیا کا چکر لگا لیا تھا۔ اس وقت تک، صارف نے تخفیف کے اقدامات کیے تھے، لیکن پیداوار میں صورت حال کے دوبارہ ہونے سے خوفزدہ تھا، کیونکہ اس کی بنیادی وجہ ابھی تک دریافت نہیں ہوئی تھی۔

ٹکٹ کے زیورخ پہنچنے تک، ہمارے پاس پہلے سے ہی درج ذیل معلومات موجود تھیں۔

• مواد /etc/hosts
• مواد /etc/resolv.conf
• آؤٹ پٹ iptables-save
• ٹیم کی طرف سے جمع ngrep pcap فائل

اس ڈیٹا کے ساتھ، ہم "تحقیقات" اور خرابیوں کا سراغ لگانے کا مرحلہ شروع کرنے کے لیے تیار تھے۔

ہمارے پہلے اقدامات

سب سے پہلے، ہم نے میٹا ڈیٹا سرور کے لاگ اور اسٹیٹس کو چیک کیا اور اس بات کو یقینی بنایا کہ یہ صحیح طریقے سے کام کر رہا ہے۔ میٹا ڈیٹا سرور IP ایڈریس 169.254.169.254 کا جواب دیتا ہے اور دوسری چیزوں کے علاوہ، ڈومین ناموں کو کنٹرول کرنے کا ذمہ دار ہے۔ ہم نے یہ بھی دو بار چیک کیا کہ فائر وال VM کے ساتھ صحیح طریقے سے کام کرتا ہے اور پیکٹ کو بلاک نہیں کرتا ہے۔

یہ ایک طرح کا عجیب مسئلہ تھا: nmap چیک نے UDP پیکٹ کے ضائع ہونے کے بارے میں ہمارے بنیادی مفروضے کی تردید کی، اس لیے ہم ذہنی طور پر ان کو چیک کرنے کے لیے کئی اور اختیارات اور طریقے لے کر آئے:

• کیا پیکٹ منتخب طور پر گرائے جاتے ہیں؟ => iptables کے قواعد کو چیک کریں۔
• کیا یہ بہت چھوٹا نہیں ہے؟ MTU? => آؤٹ پٹ چیک کریں۔ ip a show
• کیا مسئلہ صرف UDP پیکٹ یا TCP کو بھی متاثر کرتا ہے؟ => دور چلاو dig +tcp
• کیا کھود کر تیار کردہ پیکٹ واپس کیے گئے ہیں؟ => دور چلاو tcpdump
• کیا libdns صحیح طریقے سے کام کر رہا ہے؟ => دور چلاو strace دونوں سمتوں میں پیکٹ کی ترسیل کو چیک کرنے کے لیے

یہاں ہم صارف کو براہ راست مسائل کے حل کے لیے کال کرنے کا فیصلہ کرتے ہیں۔

کال کے دوران ہم کئی چیزوں کو چیک کر سکتے ہیں:

• کئی جانچ پڑتال کے بعد ہم iptables کے قواعد کو وجوہات کی فہرست سے خارج کر دیتے ہیں۔
• ہم نیٹ ورک انٹرفیس اور روٹنگ ٹیبل چیک کرتے ہیں، اور دو بار چیک کرتے ہیں کہ MTU درست ہے۔
• ہم یہ دریافت کرتے ہیں۔ dig +tcp google.com (TCP) کام کرتا ہے جیسا کہ اسے چاہیے، لیکن dig google.com (UDP) کام نہیں کرتا
• بھگا کر tcpdump یہ اب بھی کام کر رہا ہے dig، ہمیں معلوم ہوتا ہے کہ UDP پیکٹ واپس کیے جا رہے ہیں۔
• ہم بھگاتے ہیں۔ strace dig google.com اور ہم دیکھتے ہیں کہ کس طرح ڈیگ صحیح طریقے سے کال کرتا ہے۔ sendmsg() и recvms()تاہم، دوسرا ایک ٹائم آؤٹ کی وجہ سے رکاوٹ ہے۔

بدقسمتی سے، شفٹ کا اختتام آتا ہے اور ہم اس مسئلے کو اگلے ٹائم زون تک بڑھانے پر مجبور ہیں۔ تاہم، درخواست نے ہماری ٹیم میں دلچسپی پیدا کی، اور ایک ساتھی تجویز کرتا ہے کہ ابتدائی DNS پیکج scrapy Python ماڈیول استعمال کریں۔

from scapy.all import *

answer = sr1(IP(dst="169.254.169.254")/UDP(dport=53)/DNS(rd=1,qd=DNSQR(qname="google.com")),verbose=0)
print ("169.254.169.254", answer[DNS].summary())

یہ ٹکڑا ایک DNS پیکٹ بناتا ہے اور میٹا ڈیٹا سرور کو درخواست بھیجتا ہے۔

صارف کوڈ چلاتا ہے، DNS جواب واپس آ جاتا ہے، اور ایپلیکیشن اسے وصول کرتی ہے، اس بات کی تصدیق کرتی ہے کہ نیٹ ورک کی سطح پر کوئی مسئلہ نہیں ہے۔

ایک اور "دنیا بھر کے دورے" کے بعد، درخواست ہماری ٹیم کو واپس آتی ہے، اور میں اسے مکمل طور پر اپنے پاس منتقل کرتا ہوں، یہ سوچتے ہوئے کہ اگر درخواست جگہ جگہ چکر لگانا بند کر دے تو صارف کے لیے یہ زیادہ آسان ہوگا۔

اس دوران، صارف نظام کی تصویر کا سنیپ شاٹ فراہم کرنے پر رضامندی ظاہر کرتا ہے۔ یہ بہت اچھی خبر ہے: سسٹم کو خود جانچنے کی صلاحیت ٹربل شوٹنگ کو تیز تر بناتی ہے، کیونکہ مجھے اب صارف سے کمانڈ چلانے، مجھے نتائج بھیجنے اور ان کا تجزیہ کرنے کے لیے نہیں کہنا پڑے گا، میں خود سب کچھ کر سکتا ہوں!

میرے ساتھی مجھ سے تھوڑا سا حسد کرنے لگے ہیں۔ دوپہر کے کھانے کے دوران ہم تبدیلی پر تبادلہ خیال کرتے ہیں، لیکن کسی کو اندازہ نہیں ہے کہ کیا ہو رہا ہے۔ خوش قسمتی سے، صارف نے خود پہلے ہی نتائج کو کم کرنے کے لیے اقدامات کیے ہیں اور اسے کوئی جلدی نہیں ہے، اس لیے ہمارے پاس مسئلہ کو ختم کرنے کا وقت ہے۔ اور چونکہ ہمارے پاس ایک تصویر ہے، اس لیے ہم کوئی بھی ٹیسٹ چلا سکتے ہیں جس میں ہماری دلچسپی ہو۔ زبردست!

ایک قدم پیچھے ہٹنا

سسٹم انجینئر کے عہدوں کے لیے انٹرویو کے سب سے مشہور سوالات میں سے ایک یہ ہے: "جب آپ پنگ لگاتے ہیں تو کیا ہوتا ہے۔ www.google.com? سوال بہت اچھا ہے، کیونکہ امیدوار کو شیل سے لے کر صارف کی جگہ، سسٹم کے کرنل اور پھر نیٹ ورک تک ہر چیز کو بیان کرنے کی ضرورت ہے۔ میں مسکراتا ہوں: کبھی کبھی انٹرویو کے سوالات حقیقی زندگی میں کارآمد ثابت ہوتے ہیں...

میں اس HR سوال کو موجودہ مسئلے پر لاگو کرنے کا فیصلہ کرتا ہوں۔ موٹے طور پر، جب آپ DNS نام کا تعین کرنے کی کوشش کرتے ہیں، تو درج ذیل ہوتا ہے:

1. ایپلی کیشن سسٹم لائبریری کو کال کرتی ہے جیسے libdns
2. libdns سسٹم کنفیگریشن کو چیک کرتا ہے کہ اسے کس DNS سرور سے رابطہ کرنا چاہیے (ڈائیگرام میں یہ 169.254.169.254 ہے، میٹا ڈیٹا سرور)
3. libdns UDP ساکٹ (SOKET_DGRAM) بنانے اور دونوں سمتوں میں DNS استفسار کے ساتھ UDP پیکٹ بھیجنے کے لیے سسٹم کالز کا استعمال کرتا ہے۔
4. sysctl انٹرفیس کے ذریعے آپ UDP اسٹیک کو دانا کی سطح پر ترتیب دے سکتے ہیں
5. دانا نیٹ ورک انٹرفیس کے ذریعے نیٹ ورک پر پیکٹ منتقل کرنے کے لیے ہارڈ ویئر کے ساتھ بات چیت کرتا ہے۔
6. ہائپر وائزر پیکٹ کو پکڑتا ہے اور اس کے ساتھ رابطہ کرنے پر اسے میٹا ڈیٹا سرور پر منتقل کرتا ہے۔
7. میٹا ڈیٹا سرور، اپنے جادو سے، DNS نام کا تعین کرتا ہے اور اسی طریقہ کا استعمال کرتے ہوئے جواب دیتا ہے۔

میں آپ کو یاد دلاتا ہوں کہ ہم پہلے ہی کن مفروضوں پر غور کر چکے ہیں:

مفروضہ: ٹوٹی ہوئی لائبریریاں

• ٹیسٹ 1: سسٹم میں اسٹریس چلائیں، چیک کریں کہ ڈی آئی جی درست سسٹم کالز کو کال کرتا ہے۔
• نتیجہ: درست سسٹم کالز کو کہا جاتا ہے۔
• ٹیسٹ 2: srapy کا استعمال یہ چیک کرنے کے لیے کہ آیا ہم سسٹم لائبریریوں کو نظرانداز کرتے ہوئے ناموں کا تعین کر سکتے ہیں۔
• نتیجہ: ہم کر سکتے ہیں۔
• ٹیسٹ 3: libdns پیکیج اور md5sum لائبریری فائلوں پر rpm –V چلائیں۔
• نتیجہ: لائبریری کوڈ کام کرنے والے آپریٹنگ سسٹم میں موجود کوڈ سے بالکل مماثل ہے۔
• ٹیسٹ 4: اس رویے کے بغیر صارف کے روٹ سسٹم کی تصویر کو VM پر ماؤنٹ کریں، کروٹ چلائیں، دیکھیں کہ آیا DNS کام کرتا ہے
• نتیجہ: DNS درست طریقے سے کام کرتا ہے۔

ٹیسٹ پر مبنی نتیجہ: مسئلہ لائبریریوں میں نہیں ہے۔

مفروضہ: DNS کی ترتیبات میں ایک خرابی ہے۔

• ٹیسٹ 1: tcpdump کو چیک کریں اور دیکھیں کہ آیا DNS پیکٹ بھیجے گئے ہیں اور کھودنے کے بعد صحیح طریقے سے واپس آئے ہیں
• نتیجہ: پیکٹ صحیح طریقے سے منتقل ہوتے ہیں۔
• ٹیسٹ 2: سرور پر دو بار چیک کریں۔ /etc/nsswitch.conf и /etc/resolv.conf
• نتیجہ: سب کچھ درست ہے۔

ٹیسٹ پر مبنی نتیجہ: مسئلہ DNS کنفیگریشن کا نہیں ہے۔

مفروضہ: بنیادی نقصان پہنچا

• ٹیسٹ: نیا دانا انسٹال کریں، دستخط چیک کریں، دوبارہ شروع کریں۔
• نتیجہ: ایک جیسا سلوک

ٹیسٹ پر مبنی نتیجہ: دانا کو نقصان نہیں پہنچا ہے۔

مفروضہ: صارف کے نیٹ ورک کا غلط رویہ (یا ہائپر وائزر نیٹ ورک انٹرفیس)

• ٹیسٹ 1: اپنی فائر وال سیٹنگز کو چیک کریں۔
• نتیجہ: فائر وال DNS پیکٹ کو میزبان اور GCP دونوں پر منتقل کرتا ہے۔
• ٹیسٹ 2: ٹریفک کو روکیں اور DNS درخواستوں کی ترسیل اور واپسی کی درستگی کی نگرانی کریں۔
• نتیجہ: tcpdump تصدیق کرتا ہے کہ میزبان کو واپسی کے پیکٹ موصول ہوئے ہیں۔

ٹیسٹ پر مبنی نتیجہ: مسئلہ نیٹ ورک میں نہیں ہے۔

مفروضہ: میٹا ڈیٹا سرور کام نہیں کر رہا ہے۔

• ٹیسٹ 1: بے ضابطگیوں کے لیے میٹا ڈیٹا سرور لاگز کو چیک کریں۔
• نتیجہ: نوشتہ جات میں کوئی بے ضابطگی نہیں ہے۔
• ٹیسٹ 2: میٹا ڈیٹا سرور کو بذریعہ بائی پاس کریں۔ dig @8.8.8.8
• نتیجہ: میٹا ڈیٹا سرور استعمال کیے بغیر بھی ریزولوشن ٹوٹ گیا ہے۔

ٹیسٹ پر مبنی نتیجہ: مسئلہ میٹا ڈیٹا سرور کے ساتھ نہیں ہے۔

نیچے لائن: ہم نے سوائے تمام سب سسٹمز کا تجربہ کیا۔ رن ٹائم کی ترتیبات!

کرنل رن ٹائم کی ترتیبات میں غوطہ لگانا

کرنل پر عمل درآمد کے ماحول کو ترتیب دینے کے لیے، آپ کمانڈ لائن آپشنز (grub) یا sysctl انٹرفیس استعمال کر سکتے ہیں۔ میں نے دیکھا /etc/sysctl.conf اور ذرا سوچیں، میں نے کئی حسب ضرورت ترتیبات دریافت کیں۔ ایسا محسوس کرتے ہوئے جیسے میں نے کسی چیز کو پکڑ لیا ہے، میں نے تمام نان نیٹ ورک یا نان ٹی سی پی کی ترتیبات کو چھوڑ دیا، باقی پہاڑی ترتیبات کے ساتھ net.core. پھر میں وہاں گیا جہاں VM میں میزبان کی اجازتیں تھیں اور ٹوٹے ہوئے VM کے ساتھ ایک ایک کر کے سیٹنگز کو لاگو کرنا شروع کر دیا، یہاں تک کہ مجھے مجرم مل گیا:

net.core.rmem_default = 2147483647

یہ ہے، ایک DNS توڑنے والی ترتیب! مجھے قتل کا ہتھیار مل گیا۔ لیکن ایسا کیوں ہو رہا ہے؟ مجھے اب بھی ایک مقصد کی ضرورت تھی۔

بنیادی DNS پیکٹ بفر سائز کے ذریعے ترتیب دیا گیا ہے۔ net.core.rmem_default. ایک عام قدر کہیں 200KiB کے آس پاس ہوتی ہے، لیکن اگر آپ کے سرور کو بہت سارے DNS پیکٹ ملتے ہیں، تو آپ بفر کا سائز بڑھا سکتے ہیں۔ اگر نیا پیکٹ آنے پر بفر بھرا ہوا ہے، مثال کے طور پر کیونکہ ایپلی کیشن اس پر تیزی سے کارروائی نہیں کر رہی ہے، تو آپ پیکٹ کھونا شروع کر دیں گے۔ ہمارے مؤکل نے صحیح طریقے سے بفر سائز میں اضافہ کیا کیونکہ وہ ڈیٹا کے ضائع ہونے سے ڈرتا تھا، کیونکہ وہ DNS پیکٹ کے ذریعے میٹرکس جمع کرنے کے لیے ایک ایپلیکیشن استعمال کر رہا تھا۔ اس نے جو قدر سیٹ کی وہ زیادہ سے زیادہ ممکن تھی: 231-1 (اگر 231 پر سیٹ کی گئی تو دانا "غلط دلیل" لوٹائے گا)۔

اچانک مجھے احساس ہوا کہ کیوں nmap اور scapy نے صحیح طریقے سے کام کیا: وہ کچے ساکٹ استعمال کر رہے تھے! خام ساکٹ عام ساکٹ سے مختلف ہیں: وہ iptables کو نظرانداز کرتے ہیں، اور وہ بفر نہیں ہوتے ہیں!

لیکن "بفر بہت بڑا" کیوں مسائل کا سبب بنتا ہے؟ یہ واضح طور پر ارادے کے مطابق کام نہیں کرتا ہے۔

اس مقام پر میں ایک سے زیادہ دانا اور ایک سے زیادہ تقسیم پر مسئلہ کو دوبارہ پیش کرسکتا ہوں۔ مسئلہ پہلے ہی 3.x کرنل پر ظاہر ہوا تھا اور اب یہ 5.x کرنل پر بھی ظاہر ہوا ہے۔

درحقیقت، آغاز پر

sysctl -w net.core.rmem_default=$((2**31-1))

DNS نے کام کرنا چھوڑ دیا۔

میں نے ایک سادہ بائنری سرچ الگورتھم کے ذریعے ورکنگ ویلیوز کی تلاش شروع کی اور پتہ چلا کہ سسٹم 2147481343 کے ساتھ کام کرتا ہے، لیکن یہ نمبر میرے لیے نمبروں کا ایک بے معنی سیٹ تھا۔ میں نے کلائنٹ کو اس نمبر کو آزمانے کا مشورہ دیا، اور اس نے جواب دیا کہ سسٹم google.com کے ساتھ کام کرتا ہے، لیکن پھر بھی دوسرے ڈومینز کے ساتھ غلطی ہوئی، اس لیے میں نے اپنی تحقیقات جاری رکھی۔

میں نے انسٹال کر لیا ہے۔ ڈراپ واچ، ایک ٹول جو پہلے استعمال کیا جانا چاہئے تھا: یہ بالکل ظاہر کرتا ہے کہ دانا میں ایک پیکٹ کہاں ختم ہوتا ہے۔ مجرم فعل تھا۔ udp_queue_rcv_skb. میں نے کرنل کے ذرائع کو ڈاؤن لوڈ کیا اور چند کو شامل کیا۔ افعال printk یہ معلوم کرنے کے لیے کہ پیکٹ کہاں ختم ہوتا ہے۔ مجھے جلدی سے صحیح حالت مل گئی۔ if، اور کچھ دیر تک اسے گھورتا رہا، کیونکہ یہ تب تھا کہ آخرکار سب کچھ ایک مکمل تصویر میں آ گیا: 231-1، ایک بے معنی نمبر، ایک غیر کام کرنے والا ڈومین... یہ کوڈ کا ایک ٹکڑا تھا __udp_enqueue_schedule_skb:

if (rmem > (size + sk->sk_rcvbuf))
		goto uncharge_drop;

براہ مہربانی نوٹ کریں:

• rmem قسم int کا ہے۔
• size u16 قسم کا ہے (غیر دستخط شدہ سولہ بٹ انٹ) اور پیکٹ کا سائز محفوظ کرتا ہے۔
• sk->sk_rcybuf int قسم کا ہے اور بفر سائز کو ذخیرہ کرتا ہے جو تعریف کے مطابق، میں قدر کے برابر ہے۔ net.core.rmem_default

جب sk_rcvbuf 231 تک پہنچتا ہے، پیکٹ کے سائز کا خلاصہ کرنے کا نتیجہ ہو سکتا ہے۔ انٹیجر اوور فلو. اور چونکہ یہ ایک int ہے، اس کی قدر منفی ہو جاتی ہے، اس لیے شرط صحیح ہو جاتی ہے جب اسے غلط ہونا چاہیے (آپ اس کے بارے میں مزید پڑھ سکتے ہیں لنک).

غلطی کو معمولی طریقے سے درست کیا جا سکتا ہے: کاسٹ کر کے unsigned int. میں نے فکس کو لاگو کیا اور سسٹم کو دوبارہ شروع کیا اور DNS نے دوبارہ کام کیا۔

فتح کا ذائقہ

میں نے اپنے نتائج کلائنٹ کو بھیجے اور بھیجے۔ LKML دانا پیچ. میں خوش ہوں: پہیلی کا ہر ٹکڑا ایک ساتھ فٹ بیٹھتا ہے، میں بالکل واضح کر سکتا ہوں کہ ہم نے جو مشاہدہ کیا اس کا مشاہدہ کیوں کیا، اور سب سے اہم بات، ہم اپنی ٹیم ورک کی بدولت مسئلے کا حل تلاش کرنے میں کامیاب ہوئے!

یہ بات تسلیم کرنے کے قابل ہے کہ کیس نایاب نکلا، اور خوش قسمتی سے ہمیں صارفین کی جانب سے ایسی پیچیدہ درخواستیں شاذ و نادر ہی موصول ہوتی ہیں۔

ماخذ: www.habr.com