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 <pid> 3 -file ~/Desktop/sample.txt দিয়ে বা গিয়ার মেনু থেকে নেওয়া। যে অ্যাপ অনন্তকাল ঘুরতে থাকে এবং মেরে ফেলতে হয়, সে একই মেনু থেকে Spindump আইটেম পায়। ক্লায়েন্ট ও সিস্টেম দুটোই জড়ানো সমস্যা পায় sudo sysdiagnose -f ~/Desktop। সম্ভব হলে জোর করে বন্ধ করার আগে স্যাম্পল নিন, কারণ বন্ধ করা ঠিক সেই অবস্থাটিই ধ্বংস করে যা আপনি দেখতে চেয়েছিলেন, আর ফাইলের নাম কারণ সম্পর্কে আপনার অনুমানের বদলে ঘটনা ও সময় অনুসারে দিন।

প্রতিটি বান্ডলকে সংবেদনশীল হিসেবে ধরুন। এই রিপোর্টগুলোতে অ্যাকাউন্টের নাম, হোস্টনেম, পাথ ও নেটওয়ার্কের বিবরণ থাকে, তাই প্রকাশ্য থ্রেডে সংযুক্ত না করে আপনার প্রতিষ্ঠানের ব্যবহার করা সাপোর্ট চ্যানেলে পাঠান। রিপোর্ট ছাঁটতে হলে একটি কপি ছাঁটুন এবং মূলটি অক্ষত রাখুন।

যখন পয়েন্টার নিজেই নড়ে না

মৃত ইন্টারফেস কাজের ক্রম বদলে দেয়। যে শেল উত্তর দেয় না, সেখান থেকে আপনি প্রসেসের স্যাম্পল নিতে বা কোয়েরি চালাতে পারেন না, তাই প্রথম লক্ষ্য পুনরুদ্ধার আর দ্বিতীয় লক্ষ্য রেকর্ড। জোর করে রিস্টার্ট কখনও একমাত্র পথ, আর সেটিই সেই মুহূর্ত যখন সবচেয়ে দরকারি বিবরণ হারিয়ে যায়। রিস্টার্টের আগে সময়, খোলা উইন্ডো আর নেটওয়ার্ক মেনুতে সংযোগ দেখা গিয়েছিল কি না লিখুন; প্রসেসের অবস্থা না থাকলেও এসব পর্যবেক্ষণ রিবুটে টিকে থাকে।

মেশিন ফিরে এলে রিস্টার্টই অপরাধী খুঁজে পেয়েছে এই সিদ্ধান্তের বিরোধিতা করুন। এটি সেবা ফিরিয়ে দিল এবং কিছুই নাম দিল না। একটি নিয়ন্ত্রিত পরিবর্তনসহ পুনরাবৃত্তিই কেবল কোনো উপাদানের দিকে ইশারা করতে পারে।

জমাট ফিরে এলে প্রতি চেষ্টায় একটি শর্ত বদলান: নেটওয়ার্ক, ক্লায়েন্ট সংস্করণ বা ঘুমের মোড। আগে দূরবর্তী কাজ সংরক্ষণ করুন, আর প্রোডাকশন মেশিনে জোর করে ঘুমের পুনরাবৃত্তি এড়ান, কারণ বারবার কঠোর চক্রে ডেটা হারানোর ঝুঁকি থাকে এবং প্রায়ই আপনি যে ব্যর্থতার পেছনে ছুটছেন তার চেয়ে আলাদা ব্যর্থতা তৈরি হয়। প্রতিটি চেষ্টা তার শর্তসহ লিখে রাখুন যাতে পরেরটি উপাখ্যান নয়, তুলনীয় হয়।

একটি ঘটনা হস্তান্তর করুন, মেজাজ নয়

যে হস্তান্তর কাজ করায়, তা চারটি জিনিসের নাম বলে: কী সাড়া দেওয়া বন্ধ করল, কখন ঘটল, ওই মুহূর্তে নেটওয়ার্ক কেমন দেখাচ্ছিল, আর কোন ক্যাপচার ওই সময়সীমা ঢাকে। ক্লায়েন্ট সংস্করণ ও macOS বিল্ড যোগ করে থামুন। প্ল্যাটফর্ম দল ও ক্লায়েন্ট বিক্রেতা দুজনেই ওই বাক্য নিয়ে কাজ করতে পারে, আর কেউই হতাশার বর্ণনা নিয়ে কাজ করতে পারে না। রেকর্ডটি এক জায়গায় রাখুন এবং প্রতিবার গল্পটি নতুন করে বলার বদলে তাতে যোগ করুন; কোনো আপডেট আচরণ বদলে থাকলে কোনটি লিখুন, কারণ সেটিও প্রমাণ।

ভালো রেকর্ড আরও বলে আপনি ইতিমধ্যে কী বাদ দিয়েছেন। জমাটের সময় কোনো স্থানীয় অ্যাপ সাড়া দিলে তা বলুন; ঘুমের লগ লক নয়, সত্যিকারের জাগরণ দেখালে তাও বলুন। পরের ব্যক্তিকে আপনার করা পরীক্ষাগুলো আবার করতে হবে না।

টিকিট বন্ধ করার আগে তিনটি জিনিস যাচাই করুন: টাইমস্ট্যাম্প স্মৃতি থেকে নয়, ঘুমের লগ থেকে এসেছে, ক্যাপচার আপনি সত্যিই যে লক্ষণ দেখেছেন তার সঙ্গে মেলে, আর বান্ডলটি অনুমোদিত জায়গায় আছে। তিনটির কোনোটি না থাকলে রিপোর্ট পাঠানোর জন্য প্রস্তুত নয়।