কার্নেল প্যানিক লগগুলি কোথায়?


31

হ্যান্ডব্রেক / ffmpeg নিয়ে আমার সমস্যা হয়েছে। ~ 5 মিনিটের ট্রান্সকোডিংয়ের পরে কম্পিউটার লক হয়ে যায়। আমি মোটামুটি নিশ্চিত যে এটি কর্নেল আতঙ্কের কারণ ক্যাপস-লকটি ঝলকানি শুরু হয়।

কী করা উচিত এবং কয়েকটি নির্দিষ্ট বাগ সম্পর্কে কয়েকটি যৌক্তিক প্রশ্ন রয়েছে তবে আমি সত্যিই একটি জিনিসের পরে রয়েছি: সবকিছু মারা যাওয়ার আগে ঠিক কী হয়েছিল ?!

আমি যাচাই করে দেখেছি /var/log/kern.logএবং সমস্ত সময় আমি যা দেখতে পাই তা হ'ল আমি ডিভিডিতে স্টিক করছি এবং তার কয়েক মিনিট পরে, সিস্টেমটি বুট আপ হচ্ছে। কোনও ত্রুটি নেই, কোনও আতঙ্কের বিজ্ঞপ্তি নেই।

প্যানিকগুলি লগ করতে বাধ্য করার কোনও উপায় আছে কি? আমি নিশ্চিত যে আমি এটি পুনরুত্পাদন করতে পারি (এটি আমি সম্প্রতি চেষ্টা করেছি 100% এর আগে ঘটেছে) তাই আমি এই "সবেমাত্র" কাজ করার সময়, আমি খুশী কয়েকবার রিবুট করতে পেরেছি যদি এর অর্থ আমি করতে পারি আতঙ্কের কারণটি সন্ধান করুন।


ট্রান্সকোডিংয়ের সময় আপনি কোনও নির্দিষ্ট বার্তা পাবেন? সমাধানটি
সন্ধানে

পুনঃটুইট কিছু দেখায় নি, শুধু হিমশীতল।
অলি

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

উত্তর:


21

উবুন্টুতে আপনার সমস্ত সিস্টেম লগ পরিচালনা করে rsyslogযা এর কনফিগারেশনটিকে /etc/rsyslog.confএবং এর মধ্যে রাখে /etc/rsyslog.d/

কীভাবে কনফিগার করতে হবে rsyslogএবং সম্ভাব্য বিকল্পগুলি সম্পর্কে আরও তথ্যের জন্য দেখুন rsyslog.conf man page

খোলার পরে /etc/rsyslog.d/50-default.confআপনি দেখতে পাবেন যে লাইনের একটি রয়েছে

*.*;auth,authpriv.none -/var/log/syslog*

অর্থ এই যে আপনি যে ফাইলটির জন্য সন্ধান করছেন সেটি হ'ল /var/log/syslogআপনার কাছে সম্ভবত বিশাল লগ।

আপনি দেখতে পাচ্ছেন যে ফাইলটির নামও একটি দিয়ে শুরু হয় -, এর অর্থ ফাইলটি লেখার আগে ক্যাশে করা হয়েছে, এটি দুর্দান্ত তবে আপনাকে একটি খারাপ লগ দিয়ে ছেড়ে দিতে পারে, আপনি যা চান তা হ'ল লগ কোনও সমস্যা হওয়ার সাথে সাথেই লেখা হয়। ড্যাশ সরান এবং পুনরায় বুট করুন বা পুনরায় লোড করুন rsyslogএবং তারপরে আপনার কম্পিউটারটিকে আবার ক্র্যাশ করুন, চেক করুন /var/log/syslog


1
পুনরায় বুট করা "/", চেক করা / var / লগ / syslog | গ্রেপ আতঙ্ক এটা কাজ করে না. আমি কি কিছু রেখে গেলাম ?
এএআই

26

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

পরিবর্তে, আপনি নিজের অদলবদলে মেমরির বিষয়বস্তু ফেলে দিতে পারেন এবং তারপরে এটি পরে ডিবাগ করতে পারেন। এটি কার্নেল ক্রাশ / কোর ডাম্প হিসাবে পরিচিত।

উবুন্টু উইকের একটি ক্র্যাশডাম্পরেসিপ রয়েছে যা কার্যকর হতে পারে - যদিও এটি দেখতে কিছুটা পুরানো ,


10
CrashdumpRecipe লিনাক্স কার্নেল ক্র্যাশ ডাম্প (LKCD) টুল উপলব্ধ বোঝায় SourceForge - সেখানে উবুন্টু জন্য একটি প্যাকেজ বলা linux-crashdump; এই প্যাকেজটি এখনও সমস্ত সংস্করণে উপলব্ধ
মেই

3

সিরিয়াল বন্দর

সিরিয়াল বন্দর হল কম্পিউটারের মধ্যে একটি সাধারণ নিম্ন স্তরের যোগাযোগ ব্যবস্থা।

সুবিধাদি:

  • একবার সহজ সেটআপ (আপনার যদি হার্ডওয়্যার থাকে)
  • নির্ভরযোগ্য, যেহেতু ডেটা সংক্রমণ কেবল একটি সাধারণ তার এবং কার্নেল এপিআই-র উপর নির্ভর করে যা টিসিপি / আইপি সাবসিস্টেম বলার চেয়ে আতঙ্ক দ্বারা আক্রান্ত হওয়ার সম্ভাবনা কম।

downsides:

  • স্থান বাঁচানোর জন্য বেশিরভাগ আধুনিক ল্যাপটপের আর সিরিয়াল পোর্ট নেই (উন্মুক্ত?)। তবে ডেস্কটপ এবং ভার্চুয়াল মেশিনগুলি এখনও তা করে।
  • আপনার ডেটা পাওয়ার জন্য সিরিয়াল পোর্ট সহ একটি দ্বিতীয় কম্পিউটারও প্রয়োজন, তবে এটি মূলত রাস্পবেরি পাই এর মতো সমস্ত এমবেডড ডেভলপমেন্ট বোর্ডের ক্ষেত্রে।
  • শারীরিক স্তর সিরিয়াল কেবল দ্বারা দৈর্ঘ্য দ্বারা সীমাবদ্ধ, সীমাহীন TCP / IP নেটওয়ার্কের বিপরীতে। এটি সিরিয়াল এবং টিসিপি / আইপি মধ্যে ইন্টারফেস যে একটি ডিভাইস সঙ্গে প্রায় কাজ করা যেতে পারে। তবে এমন ডিভাইস রয়েছে যা দুজনের মধ্যে রূপান্তরিত হয়।

সিরিয়াল বন্দরটি এরকম দেখাচ্ছে:

এবং আরপিআইতে জিপিআইওর মাধ্যমে পাওয়া যায়।

তারপরে, আপনার যদি প্রয়োজনীয় হার্ডওয়্যার থাকে, তবে দ্বিতীয় কম্পিউটার থেকে মূল কম্পিউটারে এর সাথে সংযোগ করুন:

screen /dev/ttyS0 115200

এটি আসলে আপনাকে একটি শেল দেয়।

তারপরে মূল মেশিনে, আতঙ্কিত হয়ে যাওয়া অপারেশনটি শুরু করুন।

আতঙ্ক দেখা দিলে, প্যানিক ডাম্পটি দ্বিতীয় মেশিনে প্রবাহিত হয় এবং আপনি টার্মিনালে স্ক্রোল করে এগুলি সমস্ত দেখতে পান।

অন্যান্য পদ্ধতি

আরও জটিল এবং কম নির্ভরযোগ্য ব্যয় করে উপরেও উল্লিখিত হার্ডওয়্যার সীমাবদ্ধতাগুলি অতিক্রম করে এমন অন্যান্য পদ্ধতি রয়েছে। উল্লেখযোগ্য পদ্ধতি:

  • নেটডাম্প: টিসিপি / আইপি দিয়ে আতঙ্ককে প্রবাহিত করে। টিসিপি / আইপি সাবসিস্টেমটি দুর্নীতিগ্রস্থ না হওয়ার উপর নির্ভর করে।
  • kdump: উল্লিখিত লিনাক্স-ক্র্যাশডাম্পের অন্তর্নিহিত প্রক্রিয়া হিসাবে উপস্থিত রয়েছে: https://askubuntu.com/a/104793/52975 ক্র্যাশ হওয়া কার্নেলটি পরীক্ষা করতে দ্বিতীয় লিনাক্স কার্নেল বুট করে। সম্ভাব্য ভুল গুলো কী কী হতে পারতো?! :-)

এই দুর্দান্ত উত্তরটিও দেখুন: https://unix.stackexchange.com/questions/60574/determining-cause-of-linux-kernel-panic

ধাপ ডিবাগিং

পরিণামে, প্যানিক আউটপুট পাওয়ার জন্য কিছু কার্নেল কার্যকারিতা কাজ করা দরকার, এবং কোনও কার্নেলের কার্যকারিতা প্যানিকের মাধ্যমে দূষিত হতে পারে।

আপনি যদি কার্নেলে জিডিবি ব্যবহার করতে পারেন তবে আতঙ্কের দরকার কার? আপনি যদি সেই হার্ডকোর হন তবে একবার দেখুন:

আপনার সম্পূর্ণ দৃশ্যমানতা (এবং পর্যাপ্ত সময়!) একবারে প্রতিটি সমস্যা হ'ল।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.