Kernel Oops เมื่อเริ่ม VPN: หลักฐานที่ควรเก็บไว้

การเริ่มไคลเอนต์ VPN เป็นเพียงจุดเวลาที่สะดวก ไม่ใช่สาเหตุ และความต่างนั้นเป็นตัวกำหนดว่าจะเกิดอะไรต่อไป เมื่อ kernel Oops เกิดขึ้นใกล้ช่วงเวลานั้น ทางเลือกคือระหว่างการเก็บรายงานข้อบกพร่องที่ใช้งานได้ กับการกระตุ้นให้เกิดแครชเดิมอีกห้าครั้งบนเครื่องโปรดักชัน เก็บสี่สิ่งก่อนรีบูต: kernel build ที่แน่นอน, trace แรกของข้อบกพร่อง, สถานะ taint และคำอธิบายสั้น ๆ ของทุกอย่างอื่นที่เปลี่ยนไปในนาทีเดียวกัน ที่เหลือคือการตีความ และการตีความรอได้จนกว่าหลักฐานจะอยู่ในที่ปลอดภัย

จับข้อบกพร่องแรก ไม่ใช่บรรทัดสุดท้าย

Oops แรกในล็อกคือสิ่งที่สำคัญ เพราะข้อบกพร่องที่ตามมาทุกครั้งอาจเป็นความเสียหายข้างเคียงจากเคอร์เนลที่ unhealthy อยู่แล้ว คัดลอกส่วนหัวพร้อม call trace เพราะส่วนหัวมีคำสั่งที่ล้มเหลวและสถานะรีจิสเตอร์ที่ระบุเส้นทางของโค้ด รายงานที่เริ่มจากบรรทัดสุดท้ายมีค่าเพียงเล็กน้อยสำหรับคนที่อ่านมันในอีกหนึ่งสัปดาห์ถัดมา

ถ้าเครื่องรีบูตไปแล้ว บัฟเฟอร์เคอร์เนลของการบูตก่อนหน้ามักยังอยู่ใน journal หากเปิดใช้ persistent storage ไว้ตอนนั้น อ่านจากไฟล์ที่บันทึกไว้แทนการสร้างภาระงานใหม่ เพราะการทำซ้ำครั้งที่สองอาจเขียนทับสิ่งที่คุณต้องการ ในกรณีที่เครื่องเก็บ journal ข้ามการรีบูตไม่ได้ คอนโซลอนุกรมหรือ netconsole คือทางเดียวที่ข้อบกพร่องจะปรากฏให้เห็น

ล็อก build ก่อนอ่านสัญลักษณ์ใด ๆ

ชื่อฟังก์ชันและออฟเซตมีความหมายก็ต่อเมื่ออ้างอิงกับไบนารีที่สร้างมันขึ้นมา ดังนั้นบันทึกสตริงรุ่นเคอร์เนลและตัวระบุ build ของดิสทริบิวชันไว้ด้วยกัน ไฟล์สัญลักษณ์จาก build อื่นชี้ไปยังบรรทัดผิดอย่างมั่นใจเต็มที่ ซึ่งแย่กว่าการไม่มีสัญลักษณ์เลย เก็บเวอร์ชันแพ็กเกจเคอร์เนล ไม่ใช่แค่หมายเลข upstream เพราะดิสทริบิวชันพอร์ตย้อนกลับจำนวนมาก

โมดูลนอกทรีสมควรมีบรรทัดของตัวเองในบันทึก เพราะเคอร์เนลที่ถูก taint จำกัดสิ่งที่ผู้ดูแลได้รับอนุญาตให้สรุป อ่านค่า taint แทนการอนุมานจากรายการโมดูล

taint ที่ไม่ใช่ศูนย์ไม่ใช่คำกล่าวหา และไม่ได้ทำให้รายงานไร้ค่า มันบอกผู้อ่านว่าองค์ประกอบใดถูกโหลดตอนเกิดข้อบกพร่อง และแฟล็กบางตัวทำให้รายงานถูกลดลำดับความสำคัญด้วยนโยบายไม่ใช่ด้วยดุลพินิจ บันทึกค่า ชื่อโมดูล และฮาร์ดแวร์กับภาระงานเดียวกันเคยรันเคอร์เนลโดยไม่มีโมดูลเหล่านั้นหรือไม่ การเปรียบเทียบสุดท้ายนั้นเองที่แยกการถดถอยใหม่จากบั๊กที่มีมานาน

แยกตัวกระตุ้นออกจากข้อบกพร่อง

การเริ่มอุโมงค์โดยปกติใช้เส้นทางที่มีอยู่แล้ว คือไดรเวอร์เครือข่าย วินัยคิว คุณสมบัติ offload หรือสถานะพลังงาน ตัวกระตุ้นอธิบายว่าเมื่อใดข้อบกพร่องปรากฏ ไม่ใช่ว่าโค้ดใดผิด และการถือตัวกระตุ้นเป็นสาเหตุทำให้เกิดชุดการเปลี่ยนแปลงการกำหนดค่าที่ไม่ได้แก้ไขอะไรเลย

อิมเมจก่อนหน้าที่ใช้งานได้คือหลักฐาน ไม่ใช่การพิสูจน์ เมื่อเปรียบเทียบ ให้เปลี่ยนทีละองค์ประกอบต่อการบูตหนึ่งครั้ง และเก็บผลไว้ที่ที่อยู่รอดได้หลังเครื่องนั้น

ตรวจสอบว่าผู้ดูแลใช้ประโยชน์อะไรได้จริง

อ่านรายงานเหมือนคนแปลกหน้าจะอ่านก่อนส่ง ถ้ามีการกำหนดค่า ลำดับที่แน่นอน และเอกลักษณ์ของ build และข้อมูลรับรองถูกเอาออกแล้ว รายงานนั้นใช้งานได้ ถ้าเป็นภาพหน้าจอของ stack trace มันจะกลับมาพร้อมคำขอข้อมูลเดิม คู่มือการตามล่าบั๊กเคอร์เนล อธิบายว่า trace ที่มีประโยชน์และสัญลักษณ์ที่ตรงกันมีหน้าตาอย่างไร

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:'

ทุกคำสั่งข้างต้นอ่านสถานะเท่านั้น และสองคำสั่งแรกควรทำงานก่อนการรีบูตครั้งถัดไปหากเครื่องยังตอบสนองได้ ในที่ที่ journal ไม่คงอยู่ สองคำสั่งนั้นคือสิ่งเดียวที่จะใช้งานได้อีกครั้ง

ปิดข้อมูลคีย์ รหัสผ่าน และทราฟฟิกที่ไม่เกี่ยวข้อง แต่เก็บชื่อฟังก์ชันและออฟเซตที่ใครบางคนต้องใช้เพื่ออ่าน trace ส่งเนื้อหาผ่านช่องทางรายงานที่ใช้กับดิสทริบิวชันหรือเคอร์เนล ไม่ใช่การแปะสาธารณะที่แนบชื่อโฮสต์ จากนั้นรอคำถามแทนการเก็บแครชเพิ่ม เพราะข้อบกพร่องที่ระบุตำแหน่งได้เทียบกับ build ที่ตรงกันคือผลลัพธ์เดียวที่ทำให้รายงานเดินหน้า ถ้าไม่มีอะไรตอบกลับ ทางเลือกสำรองคือการทำซ้ำแบบควบคุมบนฮาร์ดแวร์สำรอง ไม่ใช่บนเครื่องที่คนอื่นพึ่งพา