<السابق | المحتويات | التالي>

6.6. اختبار آلية تفريغ الأعطال

سيؤدي اختبار آلية تفريغ الأعطال إلى حدوث ذلك إعادة تشغيل النظام. في حالات معينة ، يمكن أن يتسبب ذلك في فقد البيانات إذا كان النظام تحت عبء ثقيل. إذا كنت ترغب في اختبار الآلية ، فتأكد من أن النظام في وضع الخمول أو تحت حمل خفيف جدًا.

تحقق من أن SysRQ يتم تمكين الآلية من خلال النظر في قيمة / proc / sys / kernel / sysrq معلمة النواة:

cat / proc / sys / kernel / sysrq

إذا كانت قيمة 0 يتم إرجاع التفريغ ثم يتم تعطيل ميزة إعادة التشغيل. قيمة أكبر من 1 يشير إلى أنه تم تمكين مجموعة فرعية من ميزات sysrq. ارى /etc/sysctl.d/10-magic-sysrq.conf للحصول على وصف تفصيلي للخيارات والقيمة الافتراضية. قم بتمكين التفريغ ثم أعد تشغيل الاختبار باستخدام الأمر التالي:

sudo sysctl -w kernel.sysrq = 1

بمجرد الانتهاء من ذلك ، يجب أن تصبح جذرًا ، مثل استخدام ملفات سودو لن يكون كافيا. مثل جذر مستخدم ، سيكون عليك إصدار الأمر صدى c> / proc / sysrq-Trigger. إذا كنت تستخدم اتصالاً بالشبكة ، فستفقد الاتصال بالنظام. هذا هو السبب في أنه من الأفضل إجراء الاختبار أثناء الاتصال بوحدة تحكم النظام.

هذا له ميزة جعل عملية تفريغ kernel مرئية. يجب أن تبدو مخرجات الاختبار النموذجية كما يلي:

سودو -s

[sudo] كلمة المرور لـ ubuntu:

# صدى c> / proc / sysrq-Trigger

(خالية)

....

يتم قطع بقية الإخراج ، ولكن يجب أن ترى إعادة تشغيل النظام وفي مكان ما في السجل ، سترى السطر التالي:

ابدأ: حفظ vmcore من تحطم kernel ...

بمجرد الانتهاء ، سيتم إعادة تشغيل النظام إلى وضع التشغيل العادي. ستجد بعد ذلك ملف Kernel Crash Dump والأدلة الفرعية ذات الصلة في ملف / فار / تحطم الدليل :

ليرة سورية / فار / تحطم

201809240744 kexec_cmd لينكس-صورة-4.15.0-34-عامة-201809240744.crash

إذا لم يعمل التفريغ بسبب خطأ OOM (نفاد الذاكرة) ، فحاول زيادة حجم الذاكرة المحجوزة عن طريق التحرير /etc/default/grub.d/kdump-tools.cfg. على سبيل المثال ، لحجز 512 ميغا بايت:

GRUB_CMDLINE_LINUX_DEFAULT = "GRUB_CMDLINE_LINUX_DEFAULT $ GRUB_CMDLINE_LINUX_DEFAULT Cernel = 384M-: 512M"

يجري سودو التحديث- grub ثم أعد التشغيل بعد ذلك ، ثم اختبر مرة أخرى.

<السابق | المحتويات | التالي>