Segfault של לקוח VPN על Pi? תפסו קודם את התהליך

אתם מפעילים את הלקוח, המסוף מדפיס Segmentation fault (core dumped), והשעה הבאה הולכת על צריבת הכרטיס מחדש. ההודעה הזו מתארת איך תהליך אחד מת ברגע אחד. היא לא אומרת שהלוח ניזוק, והיא גם לא מפנה חשד מספק הכוח, מהאחסון או מהתמונה.

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

התחילו מהשורה שהמעטפת הדפיסה

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

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

בררו אם קיימת תמונת זיכרון

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

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

sysctl kernel.core_pattern
ulimit -c
coredumpctl list --since "1 hour ago" --no-pager
coredumpctl info /usr/sbin/openvpn

חזרו על הקריאות במכונה שבאמת קרסה. עשייתן בהתקנה חדשה עונה על שאלה שאיש לא שאל.

התייחסו ל-dump כאל חומר הנושא סודות

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

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

בדקו מקור לפני שמחליפים משהו

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

אם גם תוכנות לא קשורות נכשלות, או שהמערכת רושמת שגיאות אחסון, כוח או קרנל, שמרו את התצפיות האלה לחקירת הפלטפורמה. הן מרחיבות את ההיקף; הן לא מוכיחות שכל segfault נובע מ-RAM כשל או מתמונה פגומה.

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