Oops de kernel la pornirea VPN-ului: dovezi care merită păstrate

Pornirea clientului VPN este un marcaj de timp convenabil, nu o cauză, iar această distincție decide ce se întâmplă în continuare. Când un Oops de kernel apare aproape de acel moment, alegerea este între a colecta un raport de eroare utilizabil și a provoca același crash încă cinci ori pe o mașină de producție. Păstrați patru lucruri înainte de repornire: build-ul exact al kernelului, prima urmă a erorii, starea taint și o scurtă descriere a tot ce s-a schimbat în același minut. Restul este interpretare, iar interpretarea poate aștepta până când dovezile sunt într-un loc sigur.

Prindeți prima eroare, nu ultima linie

Primul Oops din jurnal este cel care contează, pentru că fiecare eroare ulterioară poate fi o daună colaterală a unui kernel deja nesănătos. Copiați antetul împreună cu urma apelurilor, deoarece antetul conține instrucțiunea care a eșuat și starea registrelor care identifică calea codului. Un raport care începe la ultima linie valorează foarte puțin pentru cine îl citește o săptămână mai târziu.

Dacă mașina a repornit deja, tamponul de kernel al pornirii anterioare este adesea încă în jurnal, cu condiția ca stocarea persistentă să fi fost activă atunci. Citiți-l din fișierul salvat în loc să recreați sarcina de lucru, deoarece o a doua reproducere poate suprascrie ceea ce aveți nevoie. Acolo unde mașina nu poate ține un jurnal între reporniri, o consolă serială sau netconsole este singura cale prin care eroarea va deveni vreodată vizibilă.

Fixați build-ul înainte de a citi orice simbol

Numele funcțiilor și offseturile au sens doar față de binarul care le-a produs, așa că notați șirul versiunii kernelului și identificatorul de build al distribuției împreună. Un fișier de simboluri dintr-un alt build indică linia greșită cu deplină încredere, ceea ce este mai rău decât să nu aveți niciun simbol. Păstrați versiunea pachetului de kernel, nu doar numărul upstream, pentru că distribuțiile fac multe backporturi.

Modulele din afara arborelui merită propria linie în înregistrare, deoarece un kernel cu taint limitează ce poate concluziona un întreținător. Citiți valoarea taint în loc să o deduceți dintr-o listă de module.

Un taint diferit de zero nu este o acuzație și nu face raportul inutil. Spune cititorului ce componente erau încărcate când a apărut eroarea, iar unele steaguri fac ca un raport să fie scăzut în prioritate de politică și nu de judecată. Notați valoarea, numele modulelor și dacă același hardware și aceeași sarcină au rulat vreodată un kernel fără ele. Tocmai această ultimă comparație separă o regresie nouă de o eroare veche.

Separați un declanșator de un defect

Pornirea tunelului exercită de obicei o cale care exista deja: un driver de rețea, o disciplină de coadă, o funcție de offload sau o stare de alimentare. Declanșatorul explică atunci când apare eroarea, nu care cod este greșit, iar tratarea declanșatorului ca cauză duce la o serie de modificări de configurare care nu repară nimic.

O imagine anterioară funcțională este dovadă, nu demonstrație. La comparare, schimbați un singur component pe pornire și păstrați rezultatele undeva care supraviețuiește mașinii.

Verificați ce poate folosi de fapt întreținătorul

Citiți raportul așa cum l-ar citi un străin înainte de a-l trimite. Dacă configurația, secvența exactă și identitatea build-ului sunt prezente, iar acreditările au fost eliminate, raportul este utilizabil. Dacă este o captură a unei urme de stivă, va reveni cu o cerere pentru aceleași informații. Ghidul de căutare a erorilor de kernel descrie cum arată o urmă utilă și simbolurile potrivite.

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

Fiecare comandă de mai sus doar citește stare, iar primele două ar trebui rulate înainte de următoarea repornire dacă mașina mai poate răspunde la ele. Acolo unde jurnalul nu este persistent, exact acelea două sunt singurele care vor funcționa vreodată din nou.

Eliminați chei, parole și trafic nelegat, dar păstrați numele funcțiilor și offseturile de care cineva are nevoie pentru a citi urma. Trimiteți materialul pe calea de raportare care se aplică distribuției sau kernelului, nu printr-o lipire publică cu un nume de gazdă atașat. Apoi așteptați o întrebare în loc să culegeți mai multe crash-uri, pentru că o eroare localizată față de un build potrivit este singurul rezultat care duce raportul înainte. Dacă nu revine nimic, alternativa este o reproducere controlată pe hardware de rezervă, niciodată pe mașina de care depind alți oameni.