আপনি ক্লায়েন্ট চালু করেন, টার্মিনাল Segmentation fault (core dumped) ছাপে, আর পরের ঘণ্টাটি কার্ড আবার ফ্ল্যাশ করাতেই চলে যায়। ওই বার্তাটি বলে একটি প্রক্রিয়া এক মুহূর্তে কীভাবে মারা গেল। এটি বলে না যে বোর্ডটি নষ্ট, আর এটি পাওয়ার সাপ্লাই, স্টোরেজ বা ইমেজকেও দায়মুক্ত করে না।

শেল যে লাইনটি ছেপেছিল সেখান থেকে তার পিছনের প্রক্রিয়ার দিকে এগোন। কাজের তথ্য হলো কোন এক্সিকিউটেবল ব্যর্থ হয়েছে, কোন পরিবেশে, আর সংযোগের কোন পর্যায়ে।

শেলের ছাপা লাইন থেকেই শুরু করুন

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

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

মেমরি ইমেজ আছে কি না জেনে নিন

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

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

sysctl kernel.core_pattern
ulimit -c
coredumpctl list --since "1 hour ago" --no-pager
coredumpctl info /usr/sbin/openvpn

যে মেশিনে সত্যিই ক্র্যাশ ঘটেছে সেখানেই ওই পাঠগুলি পুনরাবৃত্তি করুন। নতুন ইনস্টলেশনে সেগুলি করা এমন প্রশ্নের উত্তর দেয় যা কেউ করেনি।

ডাম্পকে গোপনীয়তা বহনকারী উপাদান হিসেবে দেখুন

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

রক্ষণাবেক্ষণকারী ট্রেস চাইলে জিজ্ঞাসা করুন কোন এক্সিকিউটেবল ও লাইব্রেরি থেকে চান। যে backtrace-এর ফ্রেম প্রতিবেদিত বিল্ডের সঙ্গে মেলে না তা বিশ্বাস করা কঠিন আর ভুল পড়া সহজ।

কিছু বদলানোর আগে উৎস যাচাই করুন

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

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

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

সম্পর্কিত নিবন্ধ