VPN চালু হলে কার্নেল Oops: যে প্রমাণ রাখা উচিত

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

শেষ লাইন নয়, প্রথম ফল্ট ধরুন

লগের প্রথম Oops-ই গুরুত্বপূর্ণ, কারণ পরের প্রতিটি ফল্ট ইতিমধ্যে অসুস্থ কার্নেলের পার্শ্বক্ষতি হতে পারে। কল ট্রেসের সঙ্গে হেডার কপি করুন, কারণ হেডারেই ফল্ট ঘটানো নির্দেশ ও রেজিস্টার অবস্থা থাকে যা কোড পথ চিহ্নিত করে। শেষ লাইন থেকে শুরু হওয়া রিপোর্ট এক সপ্তাহ পরে যিনি পড়বেন তাঁর কাছে খুব কম মূল্যবান।

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

কোনো প্রতীক পড়ার আগে বিল্ড ঠিক করুন

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

ট্রি-এর বাইরের মডিউল রেকর্ডে নিজের লাইন পাওয়ার যোগ্য, কারণ taint করা কার্নেল রক্ষককে কী সিদ্ধান্তে পৌঁছাতে দেবে তা সীমিত করে। মডিউল তালিকা থেকে অনুমান না করে taint মানটি পড়ুন।

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

ট্রিগারকে ডিফেক্ট থেকে আলাদা করুন

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

আগের কাজ করা ইমেজ প্রমাণ, প্রমাণিত সত্য নয়। তুলনা করার সময় প্রতি বুটে একটি করে কম্পোনেন্ট বদলান, আর ফলাফল এমন জায়গায় রাখুন যা মেশিনের পরেও টেকে।

রক্ষক আসলে কী ব্যবহার করতে পারেন তা যাচাই করুন

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

uname -r
cat /proc/sys/kernel/tainted
journalctl -k -b -1 --no-pager | sed -n '/BUG:/,/Call Trace/p'
dmesg -T | grep -A 40 'RIP:'

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

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