Rozwiązywanie problemów w systemie Linux: kompletny i praktyczny przewodnik

Informatec Digital » Zasoby » Rozwiązywanie problemów w systemie Linux: kompletny i praktyczny przewodnik

Jeśli korzystasz z Linuksa codziennie, prędzej czy później napotkasz dziwne problemy: system się nie uruchamia, usługa zawiesza się bez wyraźnego powodu, Wi-Fi ciągle się rozłącza lub dysk twardy zaczyna wydawać niepokojące dźwięki. Te problemy wcale nie są tragedią, a wręcz przeciwnie – fantastyczną okazją do poznania wewnętrznej budowy systemu i opracowania solidnej metodologii diagnozowania problemów z Linuksem.

W przeciwieństwie do bardziej zautomatyzowanego podejścia innych systemów (takich jak narzędzia do rozwiązywania problemów w systemie Windows czy polecenia takie jak DISM/SFC), Linux oferuje rozbudowany ekosystem narzędzi diagnostycznych, szczegółowych logów i narzędzi monitorujących . Kluczem nie jest samo zapamiętywanie poleceń, ale zrozumienie procesu: jak gromadzić informacje, jak je interpretować i jak działać, aby nie pogorszyć sytuacji.

Ogólne podejście do diagnozowania problemów w systemie Linux

Rozwiązywanie problemów w Linuksie nie powinno polegać na podejściu „zobaczymy, co się stanie, jeśli tego dotknę”, ale raczej na uporządkowanym i powtarzalnym procesie opartym na logice i obserwacji . Im bardziej będziesz systematyczny, tym szybciej dotrzesz do źródła problemu i tym mniejsze prawdopodobieństwo, że coś zepsujesz po drodze.

Podstawową zasadą jest zebranie jak największej ilości informacji o błędzie, zanim cokolwiek zaczniesz robić. Oznacza to zanotowanie dokładnego komunikatu o błędzie, czasu jego pojawienia się i czynności wykonywanych bezpośrednio przed jego wystąpieniem . Szczegóły takie jak „zaczęło się po aktualizacji”, „występuje tylko w tym programie” lub „występuje po podłączeniu tego urządzenia USB” są nieocenione w diagnozie.

Warto również zwrócić uwagę, czy problem jest powtarzalny, czy pojawia się sporadycznie. Wiedza o tym, czy można celowo wywołać błąd, pozwoli na kontrolowane testowanie rozwiązań i potwierdzenie, czy rzeczywiście zadziałały.

Podczas zbierania danych, niezwykle ważne jest, aby aktywować swoją najbardziej spostrzegawczą stronę: komunikaty na ekranie, kontrolki diagnostyczne płyty głównej, nietypowe dźwięki mechaniczne dysków lub wentylatorów, zapachy spalenizny, obszary nadmiernie gorące w dotyku… Twoje zmysły (wzrok, słuch, węch i dotyk) również stanowią część zestawu diagnostycznego , zwłaszcza gdy podejrzewasz fizyczny problem sprzętowy.

Mając już wstępne informacje, kolejnym logicznym krokiem jest zawężenie źródła awarii : czy jest ono związane z oprogramowaniem (jądro, system plików, usługi, aplikacje), konfiguracją (sieć, uprawnienia, sterowniki), czy sprzętem (pamięć RAM, dysk, temperatura, zasilacz, karta sieciowa, karta graficzna itp.)? Ta klasyfikacja pomoże Ci wybrać odpowiednie narzędzia w każdym przypadku.

Kluczowe zasady rozwiązywania problemów w systemie Linux

Dobra diagnoza opiera się na kilku podstawowych zasadach, które należy jak najszybciej przyswoić. Pierwszą z nich jest metodyczne gromadzenie danych : nie wystarczy stwierdzić, że „moje Wi-Fi nie działa”; trzeba wiedzieć, czy występują przerwy w działaniu, czy problem dotyczy tylko sprzętu, czy dotyczy konkretnej usługi, czy całej łączności, co wskazuje dziennik systemowy, czy występują błędy sterowników itp.

Następnym krokiem jest analiza zebranych informacji za pomocą odpowiednich narzędzi. Linux udostępnia bardzo szczegółowe logi systemowe, polecenia monitorowania zasobów oraz specjalistyczne narzędzia sieciowe i sprzętowe . Powszechną praktyką jest łączenie kilku źródeł: na przykład używanie journalctl i dmesg do przeglądania komunikatów jądra i usług, top lub htop do sprawdzania obciążenia systemu oraz narzędzi sieciowych, takich jak ping, ss lub tcpdump, aby sprawdzić, co dzieje się z połączeniami.

Gdy masz już rozsądną hipotezę, czas na przemyślane testowanie rozwiązań. Oznacza to wdrażanie jednej zmiany na raz, sprawdzanie rezultatu i cofanie go, jeśli nie działa . Nigdy nie należy tworzyć „koktajlu” jednoczesnych zmian, ponieważ jeśli problem zniknie, nie będzie wiadomo, która z nich go rozwiązała, a jeśli się pogorszy, nie będzie wiadomo, co go zepsuło.

Kolejnym fundamentalnym filarem, często pomijanym, jest dokumentacja. Rejestrowanie wykonywanych poleceń, modyfikowanych plików i uzyskiwanych wyników pozwala na powielenie skutecznego rozwiązania, dzielenie się nim z innymi i unikanie marnowania czasu na badanie tego samego problemu tygodniami później . Co więcej, dzielisz się swoimi notatkami na forach lub wiki, przyczyniając się do rozwoju społeczności Linuksa.

Na koniec pamiętaj o zasadzie prostoty. Im bardziej złożony jest system, z usługami, demonami i warstwami abstrakcji, tym większe ryzyko awarii. Zawsze, gdy to możliwe, staraj się, aby system był jak najprostszy i najbardziej przejrzysty : mniej zbędnych usług, mniej redundantnego oprogramowania, mniej egzotycznych warstw. To zmniejsza powierzchnię, na której mogą pojawić się problemy, i znacznie ułatwia diagnozę.

Przygotuj system przed dotknięciem czegokolwiek: kopie zapasowe i aktualizacje

Zanim zaczniesz modyfikować konfiguracje, naprawiać systemy plików lub aktualizować kernele, upewnij się, że w razie problemów będziesz mógł odzyskać swoje dane. Kopie zapasowe w systemie Linux to Twoja siatka bezpieczeństwa , zwłaszcza gdy będziesz pracować z krytycznymi partycjami, dyskami lub usługami.

Bardzo elastyczną opcją jest użycie rsync do tworzenia przyrostowych kopii zapasowych. Zazwyczaj łączy się go z opcjami takimi jak -a (tryb pliku, zachowuje uprawnienia, właściciela i daty), -v (wyjście pionowe) oraz parametrem postępu, aby śledzić postęp tworzenia kopii zapasowej. Ważne jest, aby mieć dostępny katalog docelowy z wystarczającą ilością miejsca, najlepiej na dysku zewnętrznym lub na partycji oddzielonej od systemu.

Jeśli wolisz spakować wszystko do jednego pliku, możesz użyć polecenia tar z parametrami takimi jak -c do utworzenia archiwum, -z do kompresji gzip, -v do podglądu postępu i -f do określenia nazwy pliku wynikowego. Następnie zaleca się sprawdzenie integralności kopii zapasowej, wyświetlając jej zawartość za pomocą samego polecenia tar, aby upewnić się, że plik kopii zapasowej nie jest uszkodzony.

Jeśli chodzi o miejsce docelowe, kluczem jest to, aby kopia zapasowa nie znajdowała się na tym samym dysku co system, który chcesz chronić. Rozsądnym wyborem będzie zewnętrzny dysk USB, chmura z narzędziami takimi jak rclone lub osobna partycja . Chodzi o to, aby w razie awarii dysku głównego lub bezużyteczności systemu mieć z czego przywrócić dane.

Kolejnym wysoce zalecanym krokiem wstępnym jest aktualizacja systemu . Wiele problemów znika po prostu przez zainstalowanie poprawionych wersji pakietów i jąder. W Debianie/Ubuntu powszechną praktyką jest uruchomienie sekwencji aktualizacji listy pakietów, a następnie aktualizacja zainstalowanych pakietów i sprawdzenie wyników pod kątem błędów. W Fedorze i jej pochodnych polecenia aktualizacji pakietów pełnią podobną funkcję, podobnie jak polecenie ` pacman -Syu` w Arch Linux, gdzie utrzymywanie systemu na bieżąco jest szczególnie ważne ze względu na format dystrybucji ciągłej.

Podstawowe kontrole sprzętu: procesora, pamięci RAM, dysków i czujników

Gdy system działa bardzo wolno, zawiesza się losowo lub restartuje bez wyraźnego powodu, nie zakładaj od razu, że to wina oprogramowania. Często przyczyną problemu jest zdegradowany sprzęt, nadmierna temperatura lub wadliwe moduły pamięci.

Aby uzyskać przegląd swojego sprzętu, możesz użyć poleceń takich jak `lshw` (szczegółowe informacje o urządzeniu), `lsblk` (lista dysków i partycji) lub konkretnych narzędzi, takich jak `dmidecode` , które wyodrębnia dane z BIOS-u/UEFI. Na przykład ` dmidecode -t memory` wyświetli informacje o zainstalowanych modułach RAM (typ DDR, pojemność itp.), a ` dmidecode -t 16` wyświetli maksymalną pojemność pamięci obsługiwaną przez płytę główną . Więcej informacji na temat zarządzania pamięcią znajdziesz w artykule Zarządzanie pamięcią w systemie Linux.

Jeśli chcesz szybko przejrzeć komponenty pamięci, polecenie `lshw -short -C memory` zapewnia zwięzłe podsumowanie, a polecenie `dmidecode --type memory | grep -E "Speed|Configured Clock Speed"` pozwala porównać nominalną prędkość modułów z prędkością skonfigurowaną przez chipset. To dobry sposób na sprawdzenie na przykład, czy moduł obsługujący 3200 MT/s działa z prędkością 2400 MT/s, ponieważ dzieli kanał z wolniejszym modułem.

Monitorowanie temperatury to kolejny kluczowy aspekt. Pakiet lm-sensors umożliwia odczyt temperatury i napięcia z procesora i innych czujników na płycie głównej. Po instalacji zaleca się uruchomienie polecenia `sudo sensors-detect` w celu wykrycia i aktywacji wszystkich dostępnych czujników, a następnie użycie poleceń takich jak `watch -n 2 sensors` w celu monitorowania w czasie rzeczywistym, czy procesor lub pamięć RAM się przegrzewają.

W przypadku dysków twardych (HDD SATA lub SSD) narzędzia takie jak hddtemp umożliwiają odczyt temperatury urządzenia, natomiast pakiet psensor lub narzędzia graficzne, takie jak xsensors, zapewniają historyczne i graficzne widoki temperatur. Na przykład, gdy dysk SSD stale pracuje na granicy swojego zakresu temperatur, jest to wyraźny sygnał, że coś jest nie tak z chłodzeniem lub obciążeniem.

Diagnostyka stanu dysków i systemu plików

Awarie dysków i błędy systemu plików są przyczyną niezliczonych problemów, od uszkodzonych plików po problemy z uruchomieniem systemu. Linux oferuje kilka narzędzi do sprawdzania stanu fizycznego dysku i logicznej integralności systemu plików.

Na początek możesz wyświetlić listę podłączonych urządzeń pamięci masowej za pomocą poleceń takich jak `lsblk -fm` lub `fdisk -l` , filtrując w razie potrzeby wirtualne dyski z pętlą zwrotną. Pozwala to zweryfikować, które dyski i partycje są rozpoznawane przez system, ich systemy plików oraz punkty montowania.

Pakiet smartmontools (z poleceniem smartctl) jest niezbędny do wykorzystania technologii SMART wbudowanej w nowoczesne dyski twarde. Najpierw należy upewnić się, że SMART jest włączony na dysku za pomocą odpowiedniego polecenia aktywującego. Następnie można sprawdzić atrybuty, takie jak Power_On_Hours , aby zobaczyć, ile godzin dysk był uruchomiony, lub uruchomić polecenie smartctl -H, aby szybko ocenić stan urządzenia.

Oprócz natychmiastowych kontroli, smartctl umożliwia uruchamianie automatycznych testów diagnostycznych : krótkiego testu do szybkiej kontroli oraz długiego lub rozszerzonego testu do znacznie dokładniejszej analizy. Następnie można przejrzeć wyniki i szczegółowe atrybuty za pomocą polecenia wyświetlającego wszystkie informacje o dysku. Jeśli wykryjesz realokację sektorów, narastające błędy lub stan „przed awarią”, czas pomyśleć o wymianie dysku.

Innym ważnym narzędziem jest fsck , który sprawdza i naprawia błędy logiczne w systemach plików. Uruchomienie fsck na partycji wiąże się z pewnym ryzykiem, jeśli zawiera ona ważne dane, dlatego kopia zapasowa jest niezbędna . Można połączyć to narzędzie z funkcją badblocks , aby zlokalizować i oznaczyć uszkodzone sektory, dzięki czemu system będzie ich unikał w przyszłości. Jeśli jednak pojawi się wiele uszkodzonych sektorów, zaleca się wymianę dysku.

Aby zdiagnozować problemy z przestrzenią, polecenie `df -h` wyświetla użycie partycji w gigabajtach, natomiast `df -i` ujawnia procent zużytych inodów. Jest całkiem możliwe, że gigabajty są wolne, ale 100% inodów jest zajęte, co spowoduje błędy podczas tworzenia nowych plików pomimo dostępnego miejsca . Jest to typowa sytuacja na serwerach obsługujących miliony małych plików.

Analiza pamięci: błędy ECC, testowanie i stabilność

Wadliwa pamięć RAM może powodować szeroki zakres objawów, od prostych, losowych awarii po ukryte uszkodzenia danych. Jeśli system korzysta z pamięci ECC, sam sprzęt może naprawić pewne błędy, ale to nie znaczy, że można zapomnieć o problemie: skorygowane błędy są oznaką, że moduł zaczyna szwankować.

Systemy Linux mogą udostępniać te informacje za pośrednictwem podsystemu EDAC . Po zainstalowaniu odpowiednich modułów w logach systemowych pojawią się komunikaty rozróżniające błędy skorygowane (CE) i błędy nienaprawialne (UE). Te pierwsze oznaczają, że sprzęt naprawił uszkodzony bit, podczas gdy te drugie zazwyczaj powodują natychmiastowy alarm jądra (kernel panic), zapobiegający zapisaniu uszkodzonych danych na dysku.

Prostym sposobem sprawdzenia, czy jądro zarejestrowało błędy EDAC, jest przejrzenie wyników polecenia `dmesg | grep EDAC` . Jeśli w tym samym module występują powtarzające się błędy EDAC, polecenie to wyraźnie wskazuje, który bank pamięci należy wymienić, zanim błędy staną się nie do naprawienia. Aby poznać zaawansowane techniki i narzędzia, zapoznaj się z tym przewodnikiem dotyczącym debugowania pamięci w systemie Linux.

Do dokładniejszych testów często używa się zewnętrznych narzędzi, takich jak memtest86 , uruchamianych z dysku zewnętrznego (USB lub podobnego). Narzędzia te poddają pamięć RAM intensywnym cyklom odczytu/zapisu w celu wykrycia błędów, które mogłyby pozostać niezauważone przez miesiące przy normalnym użytkowaniu . Zaleca się przeprowadzenie kilku uruchomień testu, aby uzyskać względną pewność.

Można również poddać system ogólnemu obciążeniu za pomocą narzędzi, takich jak testy obciążeniowe , które obciążają procesor, wejścia/wyjścia i pamięć przez określony czas, obserwując, czy występują awarie, błędy jądra (oops) lub paniki. Jeśli system powtarzalnie ulega awarii pod obciążeniem, prawdopodobnie występuje problem sprzętowy (temperatura, zasilanie, pamięć RAM) lub niestabilność jądra lub sterowników.

Monitorowanie systemu: procesor, procesy, wejście/wyjście i procesor graficzny

Aby zrozumieć, co dzieje się na Twoim komputerze w danym momencie, potrzebujesz dobrych narzędzi monitorujących. Linux oferuje kilka narzędzi konsolowych, które pozwalają na pierwszy rzut oka zobaczyć, które procesy zużywają najwięcej zasobów procesora, pamięci, wejścia/wyjścia dysku lub karty graficznej.

Klasyczne polecenia, takie jak `top` lub jego bardziej przyjazna dla użytkownika wersja `htop`, pokazują aktywne procesy, użycie procesora, użycie pamięci i średnie obciążenie. Do monitorowania aktywności dysku dla każdego procesu bardzo pomocne jest polecenie `iotop` , natomiast `nmon` zapewnia kompleksowy przegląd wielu podsystemów (procesora, pamięci, sieci i dysku) w bardzo rozbudowanym interfejsie tekstowym.

W obszarze grafiki, wykorzystanie GPU może stać się wąskim gardłem w systemach obsługujących aplikacje intensywnie korzystające z grafiki lub zadania wymagające przyspieszonego przetwarzania. W przypadku kart Intel, pakiet intel-gpu-tools zawiera polecenia takie jak intel_gpu_top , które wyświetlają w czasie rzeczywistym obciążenie GPU, kolejki wykonywania i wykorzystanie pamięci.

Jeśli pracujesz z kartami graficznymi NVIDIA, możesz użyć narzędzi Python, takich jak gpustat , lub ogólnych monitorów, takich jak Glances (z włączoną obsługą GPU), które wyświetlają zużycie pamięci wideo, wykorzystanie GPU i procesy, które z niego korzystają. W przypadku kart graficznych AMD Radeon narzędzia takie jak radeontop oferują podobne rozwiązanie, z paskami wykorzystania dla różnych jednostek wewnętrznych układu.

Jeśli podejrzewasz, że przyczyną problemu jest sterownik graficzny (błędy podczas wchodzenia do środowiska graficznego, awarie podczas korzystania z kompozytorów itp.), zaleca się sprawdzenie zainstalowanego sprzętu graficznego za pomocą poleceń takich jak `lspci -vnn | grep VGA -A 12` , `lshw -C display` lub `inxi -G` i zweryfikowanie, czy używasz sterowników open source, zastrzeżonych czy przestarzałych. W dystrybucjach takich jak Ubuntu możesz włączyć określone repozytoria sterowników graficznych (na przykład dla Radeon) i zaktualizować je do nowszych wersji zoptymalizowanych pod kątem Twojego GPU.

Diagnostyka sieci: karta sieciowa, utrata pakietów i konfiguracja

Problemy z siecią mogą obejmować komunikaty od „brak połączenia” do „wszystko działa wolno poza tą usługą”. Aby uniknąć przytłoczenia, pierwszym krokiem jest ustalenie, czy problem dotyczy komputera, sieci lokalnej, czy internetu. Linux oferuje kilka poziomów narzędzi do testowania łączności, przeglądania statystyk kart sieciowych i wykrywania utraty pakietów , a ten poradnik diagnostyki sieci IP i DNS szczegółowo omawia kontrole i rozwiązania.

Podstawowe polecenia, takie jak ping, pozwalają sprawdzić, czy można dotrzeć do konkretnego hosta (na przykład routera lub domeny zewnętrznej), a traceroute pokazuje ścieżkę, jaką pokonują pakiety do celu, co jest przydatne do określenia, w którym momencie zostały utracone. Aby sprawdzić, które porty są otwarte i które procesy z nich korzystają, ss to nowoczesny zamiennik netstat, z opcjami wyświetlania listy aktywnych połączeń TCP/UDP.

Gdy podejrzewasz, że problem leży w samej karcie sieciowej, narzędzia takie jak ethtool stają się nieocenione. Dzięki poleceniom wyświetlającym szczegółowe statystyki możesz monitorować błędy RX/TX, utracone pakiety, problemy z buforem lub przepełnienia FIFO w czasie rzeczywistym, używając kombinacji z `watch` do ciągłego odświeżania danych wyjściowych i wykrywania wzorców utraty pakietów.

Innym bardzo ilustratywnym sposobem jest sprawdzenie liczników błędów interfejsu za pomocą polecenia `netstat -ni` (lub podobnego, bardziej współczesnego narzędzia). Zobaczysz tam kolumny pakietów odebranych i wysłanych pomyślnie, a także pakietów utraconych. Jeśli odsetek utraconych pakietów (RX-DRP/RX-OK lub TX-DRP/TX-OK pomnożony przez 100) przekroczy niewielkie wartości, takie jak 0,2%, wpływ na wydajność połączenia może być drastyczny , zmniejszając efektywną prędkość o połowę lub nawet bardziej.

Nierzadko zdarza się, że nowo zakupione karty sieciowe, z powodu wad fabrycznych lub konstrukcyjnych, wykazują niedopuszczalny poziom błędów. Zmiana modelu na inny i powtórzenie testów zazwyczaj ostatecznie potwierdza, że ​​wąskim gardłem była karta sieciowa. Dlatego tak ważne jest posiadanie obiektywnych danych dotyczących utraty sygnału i błędów, zanim obwini się dostawcę internetu lub router.

Warto również sprawdzić stan urządzeń radiowych, takich jak Wi-Fi czy Bluetooth, za pomocą poleceń takich jak `rfkill` , które wskazują, czy są one blokowane programowo czy sprzętowo. W przypadku producenta, modelu i możliwości interfejsów sieciowych polecenia `lshw -C network` lub `inxi -Nx` dostarczają bardzo szczegółowych informacji, natomiast `ethtool interface_name | grep -i speed` informuje o prędkości połączenia karty (10/100/1000 Mb/s itd.).

Dzienniki systemowe i poziomy ważności w systemie Linux

Logi systemowe to Twoja księga historii: wszystko, co się wydarzyło (lub prawie wszystko), jest tam rejestrowane. Zrozumienie, jak działają i jak je filtrować, oszczędza mnóstwo czasu. W nowoczesnych systemach opartych na systemd, journalctl jest centralnym narzędziem do przeszukiwania dziennika binarnego, podczas gdy w bardziej tradycyjnych systemach pliki tekstowe nadal znajdują się w katalogu /var/log.

Do najpopularniejszych plików dziennika należą /var/log/syslog i /var/log/messages , które gromadzą ogólne zdarzenia systemowe, oraz /var/log/auth.log, który służy do analizy uwierzytelniania. Można użyć narzędzi takich jak less i grep , aby filtrować je według słów kluczowych (błąd, błąd, przekroczenie limitu czasu itp.). Podczas pracy z dziennikiem systemd można przeglądać komunikaty z ostatniego uruchomienia systemu, korzystając z określonych opcji, przeglądać logi z konkretnej usługi lub filtrować według przedziałów czasowych (na przykład z ostatnich dwóch godzin).

Polecenie `dmesg` wyświetla bufor komunikatów jądra, który jest bardzo przydatny do wykrywania problemów sprzętowych, takich jak usuwanie sterowników z pamięci, błędy magistrali PCI, ostrzeżenia dotyczące pamięci i inne. Parametr `-T` zapewnia czytelne znaczniki czasu, a filtrowanie według poziomu ważności pozwala skupić się na najbardziej krytycznych problemach. Ponadto, ` dmesg -w` umożliwia podgląd generowanych komunikatów w czasie rzeczywistym, co jest bardzo praktyczne podczas podłączania/odłączania urządzeń lub w przypadku podejrzenia błędu poprzedzającego panikę jądra.

Wiadomości są kategoryzowane według poziomów ważności, co ułatwia ustalenie priorytetów. Poziomy wahają się od 0 (awaryjny) , oznaczającego wyjątkowo poważną sytuację, która może spowodować awarie lub poważną niestabilność, poprzez 1 (alert) , 2 (krytyczny) i 3 (błąd niekrytyczny) , aż po ostrzeżenia (poziom 4), zauważalne alerty (poziom 5), komunikaty informacyjne (poziom 6) i komunikaty debugowania (poziom 7). Zrozumienie tych poziomów pozwala odfiltrować szum informacyjny i skupić się na tym, co naprawdę ważne, gdy logi są bardzo szczegółowe.

Użycie polecenia grep do potokowania wierszy pozwala wyodrębnić tylko te wiersze z określonego poziomu w logach tekstowych, podczas gdy narzędzia systemd oferują określone parametry filtrowania według priorytetu w dzienniku. Opanowanie tych filtrów to różnica między zagubieniem się w tysiącach wierszy a znalezieniem wiadomości, która da Ci potrzebną wskazówkę w ciągu kilku sekund.

Rodzaje błędów w systemie Linux: jądro, system plików, sieć, aplikacje i sprzęt

Aby postawić dokładną diagnozę, ważne jest, aby wiedzieć, jaki rodzaj błędu występuje. Problemy z Linuksem można ogólnie podzielić na błędy jądra, systemu plików, sieci, aplikacji i sprzętu , choć często są one ze sobą powiązane.

Błędy jądra obejmują zarówno proste ostrzeżenia, jak i sytuacje krytyczne, takie jak „oops” i „kernel panics”. „ oops” to poważny błąd, w którym jądro zamyka proces, który spowodował błąd, ale próbuje kontynuować działanie. Może to być objawem niedoboru pamięci, wadliwych sterowników, niezgodności, uszkodzenia danych lub błędów. Jeśli problem dotyczy krytycznego podsystemu, „oops” może przerodzić się w „ kernel panic” , czyli linuksowy odpowiednik klasycznego niebieskiego ekranu śmierci, który występuje w innych systemach.

Panika jądra to „twarda panika”: system niemal całkowicie się zawiesza, na ekranie wyświetlany jest komunikat o błędzie (często zagadkowy), a w zależności od konfiguracji może wymusić automatyczny restart. Zazwyczaj jest ona spowodowana nieprawidłowym dostępem do pamięci, awarią niezbędnych sterowników, niedostępnością partycji głównej, poważnymi problemami z pamięcią RAM, awariami procesu init, błędami w initramfs, nieprawidłowo zainstalowanymi lub nieobsługiwanymi jądrami lub niestabilnymi poprawkami. Samo jądro może wykonać zrzut pamięci (ang. Kernel Crash Dump) w celu późniejszej analizy.

Błędy systemu plików objawiają się brakiem możliwości zamontowania partycji, komunikatami o uszkodzeniu, niemożnością odczytu plików lub utratą danych. Przyczyną mogą być nagłe wyłączenia systemu, przerwy w zasilaniu, uszkodzone sektory lub błędy w sterowniku systemu plików. W takich sytuacjach pomocne są fsck, smartctl i wszelkie kopie zapasowe wykonane przed wprowadzeniem jakichkolwiek zmian.

W sieciach komputerowych objawy mogą obejmować sporadyczne rozłączenia, niską prędkość transferu, wysokie opóźnienia lub całkowity brak możliwości nawiązania połączenia. Przyczynami mogą być nieprawidłowa konfiguracja (adres IP, routing, DNS, zapora sieciowa), wadliwe sterowniki kart sieciowych, zakłócenia Wi-Fi, błędy w okablowaniu fizycznym lub przeciążenie sieci na pewnym odcinku łącza. Omówione narzędzia diagnostyczne sieci pomagają zidentyfikować warstwę, w której występuje awaria.

Błędy aplikacji obejmują nieoczekiwane zamykanie się programów, brak możliwości ich uruchomienia, wyświetlanie brakujących komunikatów bibliotecznych lub brak reakcji. Często są one spowodowane uszkodzonymi zależnościami, niezgodnymi wersjami bibliotek, błędami kodu, źle napisanymi skryptami lub sytuacjami wyścigu. Narzędzia takie jak strace (do śledzenia wywołań systemowych) lub lsof (do przeglądania otwartych plików i połączeń sieciowych procesu) mogą dostarczyć cennych informacji.

Wreszcie, błędy sprzętowe obejmują luźne złącza, uszkodzone kable, zepsute porty lub nagromadzony brud, a także awarie elektroniczne spowodowane przegrzaniem, wilgocią lub starzeniem się sprzętu. Obejmuje to również konflikty między komponentami (IRQ, DMA itp.) oraz problemy z zasilaniem lub wydajnością (ograniczenie temperatury, niewystarczająca ilość pamięci RAM, niedostateczna moc procesora). Ponownie, wykorzystanie zmysłów w połączeniu z narzędziami monitorującymi i testami obciążeniowymi pomoże Ci zidentyfikować, który komponent fizyczny ulega awarii.

Praktyczne kroki w celu uporządkowanego procesu diagnostycznego

Chociaż każdy problem jest unikalny, można zastosować pewien „szkielet” kroków, który można dostosować do niemal każdej sytuacji. Pierwszym, wspomnianym już, jest precyzyjne zdefiniowanie problemu : co jest nie tak, od kiedy, w jakich warunkach i co uległo zmianie tuż przedtem (instalacja oprogramowania, aktualizacja, wymiana sprzętu itp.). Im bardziej wiarygodne jest odtworzenie awarii, tym lepiej.

Drugim krokiem jest przegląd stanu systemu i logów: użyj journalctl i dmesg , aby wyszukać istotne komunikaty (zwłaszcza na poziomie błędu, krytycznym lub alertu), sprawdź obciążenie za pomocą top/htop , zwolnij pamięć za pomocą poleceń memory usage, użycie dysku za pomocą df oraz logi specyficzne dla danej usługi lub aplikacji. Wyszukiwanie słów kluczowych, takich jak error, fail, panic lub timeout, zazwyczaj daje szybkie wskazówki.

Po trzecie, warto zbadać źródła zewnętrzne. Dobrze sformułowane wyszukiwanie komunikatu o błędzie (na przykład „Ubuntu 20.04 rozłącza się z siecią Wi-Fi”) często doprowadzi Cię do wątków na forum, wiki dotyczących Twojej dystrybucji lub raportów o błędach, w których inni użytkownicy już doświadczyli tego samego problemu. Nie zapomnij zajrzeć do podręcznika (man), oficjalnej dokumentacji, poradników i wiki ; ten słynny plik „RTFM” pozostaje jedną z najlepszych rad.

Gdy masz już kilka hipotez, przechodzisz do etapu testowania: ponowne uruchomienie określonej usługi, tymczasowa modyfikacja pliku konfiguracyjnego (z kopią zapasową), wyłączenie modułu jądra, uruchomienie z innym jądrem dostępnym w menedżerze rozruchu, przetestowanie innego urządzenia fizycznego itd. Kluczem jest tutaj wprowadzanie odwracalnych i kontrolowanych zmian, jedna po drugiej , i sprawdzanie po każdym kroku, czy problem nadal występuje.

Gdy w końcu znajdziesz rozwiązanie eliminujące błąd, pozostaje jeszcze jeden, często niedoceniany krok: sprawdzenie jego stabilności w czasie i udokumentowanie wykonanych czynności . Najlepiej zrestartować komputer (jeśli problem dotyczył uruchamiania) lub pozostawić system na chwilę pod obciążeniem, sprawdzić, czy w dziennikach nie pojawiają się żadne błędy, i zapisać rozwiązanie we własnym dzienniku technicznym. To doświadczenie pomoże Ci zapobiec ponownemu wystąpieniu problemu lub rozwiązać go w ciągu kilku minut następnym razem.

Dzięki temu całemu zestawowi pomysłów, narzędzi i metod, Linux przestaje być tajemniczą czarną skrzynką, a staje się środowiskiem, w którym można z dużą dokładnością zdiagnozować wszystko – od prostego komunikatu logu po panikę jądra czy awarię pamięci RAM . Nie chodzi o zapamiętywanie tysiąca poleceń, ale o przyswojenie systematycznego podejścia, poleganie na dokumentacji i społeczności oraz brak obawy przed zaglądaniem „pod maskę”, gdy coś pójdzie nie tak.