Oops של הליבה בעת הפעלת VPN: ראיות שכדאי לשמור

הפעלת לקוח ה-VPN היא חותם זמן נוח ולא סיבה, וההבחנה הזו קובעת מה יקרה בהמשך. כאשר Oops של הליבה מתרחש סמוך לאותו רגע, הבחירה היא בין איסוף דוח תקלה שימושי לבין עוררות אותה קריסה חמש פעמים נוספות על מכונת ייצור. שמרו ארבעה דברים לפני האתחול: את בניית הליבה המדויקת, את עקבות התקלה הראשונה, את מצב ה-taint ותיאור קצר של כל השאר שהשתנה באותה דקה. השאר הוא פרשנות, והפרשנות יכולה להמתין עד שהראיות יהיו במקום בטוח.

לתפוס את התקלה הראשונה, לא את השורה האחרונה

ה-Oops הראשון ביומן הוא זה שחשוב, כי כל תקלה מאוחרת יותר עלולה להיות נזק לוואי של ליבה שכבר אינה בריאה. העתיקו את הכותרת יחד עם עקבות הקריאות, שכן הכותרת נושאת את ההוראה שנכשלה ואת מצב האוגרים שמזהה את נתיב הקוד. דוח שמתחיל בשורה האחרונה שווה מעט מאוד למי שיקרא אותו שבוע לאחר מכן.

אם המכונה כבר אותחלה, מאגר הליבה של האתחול הקודם נמצא לעיתים קרובות עדיין ביומן, בתנאי שאחסון מתמיד היה מופעל אז. קראו אותו מהקובץ השמור במקום לשחזר את העומס, כי שחזור שני עלול לדרוס את מה שדרוש לכם. כאשר המכונה אינה יכולה לשמור יומן בין אתחולים, קונסולה טורית או netconsole היא הדרך היחידה שהתקלה תהיה גלויה אי פעם.

לנעול את הבנייה לפני קריאת כל סמל

לשמות פונקציות ולהיסטים יש משמעות רק ביחס לקובץ הבינארי שהפיק אותם, לכן רשמו יחד את מחרוזת מהדורת הליבה ואת מזהה הבנייה של ההפצה. קובץ סמלים מבנייה אחרת מצביע על השורה הלא נכונה בביטחון מלא, וזה גרוע מלא להחזיק סמל כלל. שמרו את גרסת חבילת הליבה, לא רק את מספר ה-upstream, כי הפצות מעבירות הרבה לאחור.

מודולים מחוץ לעץ ראויים לשורה משלהם ברשומה, כי ליבה עם taint מגבילה מה מותר לתחזוקן להסיק. קראו את ערך ה-taint במקום להסיק אותו מרשימת מודולים.

taint שאינו אפס אינו האשמה ואינו הופך את הדוח לחסר ערך. הוא אומר לקורא אילו רכיבים היו טעונים כשהתקלה אירעה, וכמה דגלים גורמים לדוח לקבל עדיפות נמוכה יותר מכוח מדיניות ולא מכוח שיקול דעת. רשמו את הערך, את שמות המודולים ואם אותו חומרה ואותו עומס אי פעם הריצו ליבה בלעדיהם. ההשוואה האחרונה היא מה שמפריד רגרסיה חדשה מבאג ותיק.

להפריד טריגר מפגם

הפעלת המנהרה מפעילה בדרך כלל נתיב שכבר היה קיים: דרייבר רשת, משמעת תור, תכונת offload או מצב צריכת חשמל. הטריגר מסביר מתי התקלה מופיעה, לא איזה קוד שגוי, והתייחסות לטריגר כאל הסיבה מובילה לשורה של שינויי תצורה שלא מתקנים דבר.

תמונה קודמת שעובדת היא ראיה, לא הוכחה. שנו רכיב אחד בכל אתחול בעת ההשוואה, ושמרו את התוצאות במקום שישרוד את המכונה.

לבדוק מה התחזוקן באמת יכול להשתמש בו

קראו את הדוח כמו שזר היה קורא אותו לפני שליחה. אם התצורה, הרצף המדויק וזהות הבנייה נמצאים, והאישורים הוסרו, הדוח שמיש. אם זה צילום מסך של עקבות מחסנית, הוא יחזור עם בקשה לאותו מידע. מדריך ציד הבאגים של הליבה מתאר איך נראים עקבה שימושית וסמלים תואמים.

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

כל פקודה למעלה רק קוראת מצב, ואת שתי הראשונות יש להריץ לפני האתחול הבא אם המכונה עדיין יכולה לענות עליהן. כאשר היומן אינו מתמיד, שתי אלו הן היחידות שיעבדו שוב אי פעם.

הסירו מפתחות, סיסמאות ותנועה לא קשורה, אך שמרו את שמות הפונקציות וההיסטים שמישהו זקוק להם כדי לקרוא את העקבה. שלחו את החומר בנתיב הדיווח שחל על ההפצה או על הליבה, לא בהדבקה ציבורית עם שם מארח מצורף. ואז המתינו לשאלה במקום לקצור עוד קריסות, כי תקלה מאותרת מול בנייה תואמת היא התוצאה היחידה שמקדמת את הדוח. אם לא חוזר דבר, החלופה היא שחזור מבוקר על חומרה חלופית, ולעולם לא על המכונה שאחרים תלויים בה.