Oops в ядрото при стартиране на VPN: доказателства, които си струва да запазите

Стартирането на VPN клиента е удобна времева марка, а не причина, и това разграничение решава какво следва. Когато Oops в ядрото се появи близо до този момент, изборът е между събирането на използваем отчет за грешката и предизвикването на същия срив още пет пъти на производствена машина. Запазете четири неща преди рестарт: точната сборка на ядрото, първата следа от грешката, състоянието на taint и кратко описание на всичко останало, което се е променило в същата минута. Останалото е интерпретация и тя може да почака, докато доказателствата са на сигурно място.

Уловете първата грешка, а не последния ред

Първият Oops в журнала е този, който има значение, защото всяка следваща грешка може да е съпътстваща вреда от ядро, което вече не е здраво. Копирайте заглавката заедно с трасировката на извикванията, тъй като заглавката носи инструкцията, предизвикала грешката, и състоянието на регистрите, които идентифицират пътя на кода. Отчет, който започва от последния ред, струва много малко за всеки, който го прочете седмица по-късно.

Ако машината вече е рестартирала, буферът на ядрото от предишното зареждане често все още е в журнала, при условие че по това време е било включено постоянно хранилище. Четете го от запазения файл, вместо да пресъздавате натоварването, защото второ възпроизвеждане може да презапише това, което ви трябва. Където машината не може да пази журнал между рестартиранията, серийна конзола или netconsole е единственият начин грешката изобщо да стане видима.

Фиксирайте сборката, преди да прочетете който и да е символ

Имената на функции и отместванията имат смисъл само спрямо двоичния файл, който ги е създал, затова запишете низа за версията на ядрото и идентификатора на сборката на дистрибуцията заедно. Файл със символи от друга сборка сочи към грешния ред с пълна увереност, което е по-лошо от това да нямате никакъв символ. Пазете версията на пакета на ядрото, не само номера от upstream, защото дистрибуциите пренасят много промени обратно.

Модулите извън дървото заслужават свой ред в записа, тъй като маркираното ядро ограничава какво поддръжникът има право да заключи. Четете стойността на taint, вместо да я извеждате от списък с модули.

Ненулевият taint не е обвинение и не прави отчета безполезен. Той казва на читателя кои компоненти са били заредени при грешката, а някои флагове водят до понижаване на приоритета на отчета по политика, а не по преценка. Запишете стойността, имената на модулите и дали същият хардуер и натоварване някога са работили с ядро без тях. Именно това последно сравнение отделя нова регресия от дългогодишен дефект.

Отделете задействащия фактор от дефекта

Стартирането на тунела обикновено задейства път, който вече е съществувал: мрежов драйвер, дисциплина на опашка, функция за разтоварване или състояние на захранването. Задействащият фактор обяснява кога се появява грешката, а не кой код е сгрешен, и третирането му като причина води до поредица от промени в конфигурацията, които не поправят нищо.

Работещ по-ранен образ е улика, а не доказателство. Променяйте по един компонент на зареждане при сравнение и пазете резултатите някъде, където оцеляват след машината.

Проверете какво поддръжникът наистина може да използва

Прочетете отчета така, както би го прочел непознат, преди да го изпратите. Ако конфигурацията, точната последователност и идентичността на сборката са налице, а идентификационните данни са премахнати, отчетът е използваем. Ако това е екранна снимка на трасировка на стека, той ще се върне със заявка за същата информация. Ръководството за откриване на грешки в ядрото описва как изглеждат полезна трасировка и подходящи символи.

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

Всяка команда по-горе само чете състояние и първите две трябва да се изпълнят преди следващия рестарт, ако машината още може да им отговори. Където журналът не се пази, точно тези две са единствените, които някога ще работят отново.

Редактирайте ключове, пароли и несвързан трафик, но запазете имената на функциите и отместванията, от които някой се нуждае, за да прочете трасировката. Изпращайте материала по пътя за докладване, който се отнася за дистрибуцията или ядрото, а не чрез публично поставяне с прикачено име на хост. След това изчакайте въпрос, вместо да жънете още сривове, защото локализирана грешка срещу съответна сборка е единственият резултат, който движи отчета напред. Ако нищо не се върне, резервният вариант е контролирано възпроизвеждане на резервен хардуер, никога на машината, от която зависят други хора.