VPN کے ساتھ جاگنے کے بعد Mac جم جاتا ہے: کیا ریکارڈ کریں

جاگنے کے بعد جمے Mac کے بارے میں رپورٹیں اکثر تین ناکامیوں کو ایک شکایت میں ملا دیتی ہیں۔ اشارہ گر ہنوز حرکت کر سکتا ہے جبکہ VPN کلائنٹ کلکس کو نظرانداز کرتا ہے، کلائنٹ کام کر سکتا ہے جبکہ ایک دور دراز سیشن ختم ہو رہا ہو، یا پورا ڈیسک ٹاپ ان پٹ لینا بند کر سکتا ہے۔ ان میں سے ہر ایک کو الگ ثبوت چاہیے، اور جم جانے کے بعد پہلا منٹ طے کرتا ہے کہ آپ کون سا دیکھ رہے ہیں۔ غلط اندازہ ہر اگلے قدم کو غلط سمت میں بھیجتا ہے۔

کس نے جواب دینا بند کیا، اور کس نے صرف انتظار کرنا بند کیا

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

ہر نتیجہ کسی اور جگہ اشارہ کرتا ہے۔ ایک پھنسا ہوا سیشن ثبوت کو سرنگ کے دوسری طرف رکھتا ہے، اور Mac صرف تماشائی ہے۔ وہ کلائنٹ جو ڈیسک ٹاپ چلتے ہوئے بھی کلکس کو نظرانداز کرتا ہے تلاش کو اسی عمل اور اس کے لاگ تک محدود کرتا ہے۔ وہ مشین جو اشارہ گر کو نظرانداز کرتی ہے کچھ بھی چلانے کا اختیار ہی ہٹا دیتی ہے، کیونکہ ہر جانچ حکم کو جواب دینے والا شیل چاہیے۔

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

ایسی ٹائم لائن جو کل بھی آپ بچا سکیں

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

pmset -g log | grep -i -E 'wake|sleep'
log show --last 15m --predicate 'process == "<client-process>"' --style compact

پہلا حکم دھندلی یاد کو ایسے وقت کے نشان میں بدلتا ہے جو آپ دوسرے میں لکھ سکتے ہیں۔ لاگ کی استفسار کو کلائنٹ کے عمل اور مختصر دورانیے تک محدود کریں، پورے دن کے بجائے ایک صفحہ آؤٹ پٹ ملے گا۔ اسکرین سامنے ہوتے ہی ماڈل شناخت، کلائنٹ بلڈ اور وہ نیٹ ورک جس پر آپ تھے اسی نوٹ میں نقل کریں؛ اگلی صبح جوڑی گئی رپورٹ وہ ترتیب کھو دیتی ہے جس نے اسے پڑھنے کے قابل بنایا تھا۔

علامت سے میل کھانے والی گرفت منتخب کریں

Apple Activity Monitor کی تشخیصی گائیڈ میں تین گرفتیں بیان کرتا ہے، اور وہ الگ سوالات کے جواب دیتی ہیں۔ Sample Process ایک منتخب عمل کو تین سیکنڈ دیکھتا ہے، spindump اس ایپ کو نشانہ بناتا ہے جس نے جواب دینا بند کر دیا ہے اور اب زبردستی بند ہوگی، اور System Diagnostics سسٹم لاگ ایک بنڈل میں جمع کرتا ہے۔

عادت کے بجائے جو آپ نے دیکھا اس کی بنیاد پر منتخب کریں۔ چلتا ہے مگر برا سلوک کرتا ہے ایسا کلائنٹ sample لیتا ہے، جو sample <pid> 3 -file ~/Desktop/sample.txt سے یا گیئر مینو سے لیا جاتا ہے۔ جو ایپ بے انتہا گھومتی ہے اور اسے مارنا پڑتا ہے، اسے اسی مینو سے Spindump آئٹم ملتا ہے۔ کلائنٹ اور سسٹم دونوں کو محیط مسئلے کو sudo sysdiagnose -f ~/Desktop ملتا ہے۔ جہاں ممکن ہو زبردستی بند کرنے سے پہلے sample لیں، کیونکہ بند کرنا بالکل وہی حالت تباہ کرتا ہے جسے آپ جانچنا چاہتے تھے، اور فائل کا نام سبب کے بارے میں اپنے اندازے کے بجائے واقعے اور وقت پر رکھیں۔

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

جب اشارہ گر خود نہ ہلے

مردہ انٹرفیس کاموں کی ترتیب بدل دیتا ہے۔ جواب نہ دینے والے شیل سے آپ نہ عمل کا sample لے سکتے ہیں نہ استفسار چلا سکتے ہیں، اس لیے پہلا ہدف بحالی اور دوسرا ریکارڈ ہے۔ زبردستی دوبارہ آغاز کبھی کبھی واحد راستہ ہوتا ہے، اور یہی وہ لمحہ بھی ہے جب سب سے مفید تفصیلات غائب ہو جاتی ہیں۔ دوبارہ آغاز سے پہلے وقت، کھلی ونڈوز اور یہ لکھیں کہ نیٹ ورک مینو میں کنکشن دکھ رہا تھا یا نہیں؛ وہ مشاہدات دوبارہ بوٹ کے بعد بھی رہتے ہیں، عمل کی حالت نہیں رہتی۔

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

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

ایک واقعہ حوالے کریں، موڈ نہیں

جو حوالگی عمل پیدا کرتی ہے وہ چار چیزوں کے نام لیتی ہے: کس نے جواب دینا بند کیا، کب ہوا، اس لمحے نیٹ ورک کیسی تھی، اور کون سی گرفت اس دورانیے کو ڈھکتی ہے۔ کلائنٹ کا ورژن اور macOS بلڈ شامل کریں، پھر رک جائیں۔ پلیٹ فارم ٹیم اور کلائنٹ فروشندہ دونوں اس جملے پر عمل کر سکتے ہیں، اور کوئی بھی مایوسی کی تفصیل پر عمل نہیں کر سکتا۔ ریکارڈ ایک جگہ رکھیں اور ہر بار کہانی دوبارہ سنانے کے بجائے اس میں اضافہ کریں؛ اگر اپ ڈیٹ نے رویہ بدلا ہے تو کون سی، لکھیں، کیونکہ یہ بھی ثبوت ہے۔

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

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