Kernel Oops при стартување на VPN: докази што вреди да се зачуваат

Стартувањето на VPN клиентот е погодна временска ознака, а не причина, и таа разлика одлучува што ќе се случи потоа. Кога kernel Oops се случува близу тој момент, изборот е помеѓу собирање употреблив извештај за дефектот и предизвикување на истиот пад уште пет пати на продукциска машина. Зачувајте четири работи пред рестартирање: точниот kernel-build, првата трага од дефектот, состојбата на taint и краток опис на сѐ друго што се променило во истата минута. Останатото е интерпретација, а интерпретацијата може да почека додека доказите не бидат на безбедно место.

Фатете го првиот дефект, а не последната линија

Првиот Oops во дневникот е оној што е важен, бидејќи секој подоцнежен дефект може да биде колатерална штета од веќе нездраво јадро. Копирајте го заглавието заедно со трагата од повикувањата, бидејќи заглавието ја носи инструкцијата што предизвикала дефект и состојбата на регистрите што ја идентификуваат патеката на кодот. Извештај што започнува од последната линија вреди многу малку за оној што ќе го прочита една недела подоцна.

Ако машината веќе е рестартирана, kernel-баферот од претходното подигање често сѐ уште е во дневникот, под услов тогаш да било вклучено постојано складирање. Читајте го од зачуваната датотека наместо да го пресоздавате работното оптоварување, бидејќи второ репродуцирање може да го препише тоа што ви треба. Каде машината не може да чува дневник меѓу рестартирања, сериска конзола или netconsole е единствениот начин дефектот некогаш да стане видлив.

Фиксирајте го build-от пред да прочитате кој било симбол

Имињата на функциите и офсетите имаат значење само во однос на бинарната датотека што ги создала, затоа запишете ја низата за изданието на јадрото и идентификаторот на build-от на дистрибуцијата заедно. Датотека со симболи од друг build со целосна сигурност покажува на погрешната линија, што е полошо отколку воопшто да нема симбол. Чувајте ја верзијата на kernel-пакетот, не само upstream бројот, бидејќи дистрибуциите многу пренесуваат назад.

Модулите надвор од дрвото заслужуваат своја линија во записот, бидејќи taint-иран kernel ограничува што смее да заклучи одржувачот. Читајте ја вредноста на 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 е единствениот резултат што го движи извештајот напред. Ако ништо не се врати, резервата е контролирано репродуцирање на резервна опрема, никогаш на машината од која зависат други луѓе.