<ก่อนหน้านี้ | Contents | ถัดไป>

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

เมื่อเสร็จแล้วคุณจะต้องรูทเหมือนกับการใช้ sudo จะไม่เพียงพอ ในฐานะที่เป็น ราก ผู้ใช้คุณจะต้องออกคำสั่ง echo c > /proc/sysrq-trigger. หากคุณกำลังใช้การเชื่อมต่อเครือข่าย คุณจะสูญเสียการติดต่อกับระบบ นี่คือเหตุผลที่ควรทำการทดสอบในขณะที่เชื่อมต่อกับคอนโซลระบบ

มีข้อดีในการทำให้กระบวนการดัมพ์เคอร์เนลมองเห็นได้ ผลการทดสอบทั่วไปควรมีลักษณะดังนี้:

sudo -s

[sudo] รหัสผ่านสำหรับ Ubuntu:

# echo c > /proc/sysrq-trigger

(โมฆะ)

....

เอาต์พุตที่เหลือจะถูกตัดให้สั้นลง แต่คุณควรเห็นการรีบูตระบบ และบางที่ในบันทึก คุณจะเห็นบรรทัดต่อไปนี้:

เริ่มต้น: กำลังบันทึก vmcore จากเคอร์เนลขัดข้อง ...

เมื่อเสร็จแล้ว ระบบจะรีบูตเป็นโหมดการทำงานปกติ จากนั้นคุณจะพบไฟล์ Kernel Crash Dump และไดเร็กทอรีย่อยที่เกี่ยวข้องในไฟล์ /var/ความผิดพลาด ไดเรกทอรี :

ls /var/crash

201809240744 kexec_cmd linux-image-4.15.0-34-generic-201809240744.crash

หากการถ่ายโอนข้อมูลไม่ทำงานเนื่องจากข้อผิดพลาด OOM (หน่วยความจำไม่เพียงพอ) ให้ลองเพิ่มจำนวนหน่วยความจำที่สงวนไว้โดยแก้ไข /etc/default/grub.d/kdump-tools.cfg. ตัวอย่างเช่น หากต้องการสำรอง 512 เมกะไบต์ :

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

วิ่ง sudo update-grub แล้วรีบูตหลังจากนั้น จากนั้นทดสอบอีกครั้ง

<ก่อนหน้านี้ | Contents | ถัดไป>