Oops هسته هنگام راه‌اندازی VPN: شواهدی که ارزش نگه‌داشتن دارند

راه‌اندازی کارخواه VPN یک مهر زمانی راحت است، نه علت، و همین تفاوت تعیین می‌کند چه اتفاقی می‌افتد. وقتی یک Oops هسته نزدیک آن لحظه رخ می‌دهد، انتخاب میان گردآوری یک گزارش خطای قابل استفاده و ایجاد پنج بار دیگر همان خرابی روی ماشین تولیدی است. پیش از راه‌اندازی مجدد چهار چیز را ذخیره کنید: build دقیق هسته، نخستین رد خطا، وضعیت taint و توضیح کوتاهی از هر چیز دیگری که در همان دقیقه تغییر کرده است. بقیه تفسیر است، و تفسیر می‌تواند صبر کند تا شواهد در جای امنی باشند.

نخستین خطا را بگیرید، نه آخرین خط را

نخستین Oops در گزارش مهم است، زیرا هر خطای بعدی می‌تواند آسیب جانبی هسته‌ای باشد که از پیش ناسالم است. سرآیند را همراه با رد فراخوانی کپی کنید، چون سرآیند دستور خطادار و وضعیت ثبات‌هایی را دارد که مسیر کد را مشخص می‌کنند. گزارشی که از آخرین خط آغاز شود برای کسی که یک هفته بعد آن را می‌خواند ارزش بسیار کمی دارد.

اگر ماشین از پیش راه‌اندازی مجدد شده باشد، بافر هستهٔ بوت قبلی غالباً هنوز در ژورنال است، به شرطی که آن زمان ذخیره‌سازی پایدار فعال بوده باشد. آن را از فایل ذخیره‌شده بخوانید نه اینکه بار کاری را از نو بسازید، چون بازتولید دوم می‌تواند آنچه را لازم دارید بازنویسی کند. جایی که ماشین نمی‌تواند ژورنال را میان راه‌اندازی‌های مجدد نگه دارد، کنسول سری یا netconsole تنها راه دیده‌شدن خطاست.

پیش از خواندن هر نماد، build را تثبیت کنید

نام توابع و آفست‌ها فقط نسبت به فایل دودویی‌ای معنا دارند که آن‌ها را ساخته است، پس رشتهٔ انتشار هسته و شناسهٔ build توزیع را با هم ثبت کنید. فایل نماد از buildی دیگر با اطمینان کامل به خط اشتباه اشاره می‌کند، که از نداشتن هیچ نمادی بدتر است. نسخهٔ بستهٔ هسته را نگه دارید، نه فقط شمارهٔ upstream را، چون توزیع‌ها بسیاری از تغییرها را به عقب منتقل می‌کنند.

ماژول‌های بیرون درخت سزاوار خط خود در گزارش‌اند، چون هستهٔ taint‌شده محدود می‌کند که نگه‌دارنده چه نتیجه‌ای مجاز است بگیرد. مقدار taint را بخوانید نه اینکه آن را از فهرست ماژول‌ها استنتاج کنید.

taint غیرصفر اتهام نیست و گزارش را بی‌ارزش نمی‌کند. به خواننده می‌گوید هنگام خطا کدام اجزا بارگذاری شده بودند، و برخی پرچم‌ها باعث می‌شوند گزارش به حکم سیاست و نه داوری کم‌اولویت شود. مقدار، نام ماژول‌ها و اینکه آیا همان سخت‌افزار و بار کاری هرگز هسته‌ای بدون آن‌ها اجرا کرده‌اند را ثبت کنید. همین مقایسهٔ آخر است که یک پس‌رفت تازه را از یک باگ دیرینه جدا می‌کند.

محرک را از نقص جدا کنید

راه‌اندازی تونل معمولاً مسیری را به کار می‌گیرد که از پیش وجود داشته است: درایور شبکه، نظم صف، ویژگی offload یا وضعیت توان. محرک توضیح می‌دهد خطا چه وقت ظاهر می‌شود، نه اینکه کدام کد اشتباه است، و برخورد با محرک به‌عنوان علت به زنجیره‌ای از تغییرهای پیکربندی می‌انجامد که هیچ چیزی را درست نمی‌کند.

تصویر قبلی که کار می‌کند شواهد است، نه اثبات. هنگام مقایسه در هر بوت یک جزء را تغییر دهید، و نتایج را جایی نگه دارید که از ماشین جان سالم به در ببرد.

بررسی کنید که نگه‌دارنده واقعاً چه چیزی می‌تواند استفاده کند

پیش از فرستادن، گزارش را بخوانید همان‌گونه که یک غریبه می‌خواند. اگر پیکربندی، ترتیب دقیق و هویت build موجود است و اعتبارنامه‌ها پاک شده‌اند، گزارش قابل استفاده است. اگر تصویری از رد پشته باشد، با درخواست همان اطلاعات بازخواهد گشت. راهنمای جست‌وجوی باگ هسته توضیح می‌دهد که رد قابل استفاده و نمادهای متناظر چگونه‌اند.

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

هر فرمان بالا فقط وضعیت را می‌خواند، و دو فرمان نخست را باید پیش از راه‌اندازی مجدد بعدی اجرا کرد اگر ماشین هنوز می‌تواند به آن‌ها پاسخ دهد. جایی که ژورنال پایدار نیست، همان دو تنها فرمان‌هایی هستند که هرگز دوباره کار خواهند کرد.

کلیدها، گذرواژه‌ها و ترافیک نامرتبط را حذف کنید، اما نام توابع و آفست‌هایی را که کسی برای خواندن رد لازم دارد نگه دارید. مطالب را از مسیر گزارش‌دهی که به توزیع یا هسته مربوط است بفرستید، نه از طریق چسباندن عمومی با نام میزبان پیوست. سپس منتظر پرسش باشید نه اینکه خرابی بیشتری جمع کنید، چون خطای مکان‌یابی‌شده در برابر build متناظر تنها نتیجه‌ای است که گزارش را پیش می‌برد. اگر چیزی برنگشت، جایگزین بازتولید کنترل‌شده روی سخت‌افزار یدکی است، هرگز روی ماشینی که دیگران به آن وابسته‌اند.