Najpierw odróżnij całkowite zawieszenie hosta od awarii sieci
Zgłaszana maszyna utraciła dostęp do sieci, możliwość odpowiadania na ping, kontenery, reakcję lokalnej konsoli i wyjście wideo. Taki zakres jest szerszy niż awaria SMB, Dockera lub karty sieciowej i wskazuje na całkowite zawieszenie hosta wymagające odłączenia i ponownego podłączenia zasilania.
Jeśli serwer przestaje być dostępny zdalnie, sprawdź lokalną konsolę i obraz na ekranie, zanim kupisz zamienną kartę sieciową. Sprawna konsola kieruje dochodzenie w stronę sieci, natomiast zawieszona konsola i brak obrazu wskazują na jądro, oprogramowanie układowe, zasilanie, pamięć masową lub sprzęt.
Zapisz dokładny czas zdarzenia oraz to, czy komputer sam się uruchomił ponownie, czy pozostał włączony, ale nie odpowiadał. Te obserwacje określają, który przedział z poprzedniego uruchomienia oraz jakie dane z zewnętrznego monitoringu można porównać.
Zbierz dane z poprzedniego uruchomienia przed zmianą zmiennych
Przydatny pierwszy zestaw danych w tym wątku to journalctl -b -1, w tym komunikaty jądra i komunikaty o wysokim priorytecie z uruchomienia, które zakończyło się zawieszeniem. Zespół ZimaOS poprosił później o ostatnie 500 wpisów z poprzedniego uruchomienia oraz trwały dziennik do prywatnej analizy.
Przed publicznym opublikowaniem logów sprawdź, czy nie zawierają danych osobowych. W tym przypadku włączono trwałe rejestrowanie, ale log urywał się nagle w chwili zaobserwowanej awarii — bez paniki jądra, zabicia procesu przez OOM, resetu GPU, błędu pamięci masowej, zdarzenia termicznego, zablokowania watchdoga ani normalnego zamknięcia.
Pusty końcowy wpis nie dowodzi, że nic nie uległo awarii. Pokazuje, że host zatrzymał się, zanim dostępna lokalna ścieżka rejestrowania zdążyła zapisać przyczynę. Powtarzanie tego samego polecenia logowania po każdym identycznym, bezgłośnym zawieszeniu niewiele daje, chyba że zmieni się metoda przechwytywania.
Testy GPU i Frigate nie pozwoliły znaleźć rozwiązania
System korzystał z grafiki Intel i915 oraz Frigate VAAPI, więc autor najpierw wyłączył akcelerację GPU. Host nadal się zawieszał. Całkowite zatrzymanie Frigate w pewnym momencie wydłużyło odstęp, ale późniejsze testy nie potwierdziły, że przyczyną był Frigate.
Autor próbował również wyłączyć i915, co uniemożliwiło korzystanie z innych obciążeń, a system ostatecznie ponownie się zawiesił. Wynik ten wyklucza „wyłącz i915” jako skuteczną naprawę w tym przypadku.
Porównanie z OpenMediaVault było istotne: ten sam sprzęt i ta sama konfiguracja Frigate działały tam stabilnie. Wzbudza to podejrzenie interakcji specyficznej dla jądra lub sterownika ZimaOS, ale samo w sobie nie wskazuje, który komponent uległ awarii.
Sugestie dotyczące IOMMU, VFIO i SATA LPM wykluczono jako rozwiązania
ZimaOS początkowo zawierał intel_iommu=on oraz vfio_iommu_type1.allow_unsafe_interrupts=1. Członek zespołu poprosił autora o usunięcie obu parametrów. Aktywny wiersz poleceń potwierdził ich brak, a mimo to maszyna ponownie się zablokowała.
Autor przetestował następnie libata.force=nolpm ponieważ dyski z danymi korzystały z adaptera M.2-SATA. Następnego ranka nastąpiło kolejne zawieszenie. Wątek nie potwierdza zatem, że którakolwiek z tych zmian parametrów startowych rozwiązała problem.
Testy te pokazują również, dlaczego aktualizacje mogą unieważnić eksperyment: jedna z aktualizacji nadpisała niestandardowy plik wiersza poleceń. Zawsze sprawdzaj aktywny wiersz poleceń podczas uruchamiania przed interpretacją czasu działania i zmieniaj jedną zmienną w ramach ustalonego okna występowania awarii.
Dziennik trwały, pstore i zdalne przekazywanie osiągnęły swoje ograniczenia
Jądro zawierało pstore oraz wykrywanie twardych i miękkich blokad, a watchdog NMI był aktywny. Jednak /sys/fs/pstore pozostało puste po awariach, a na potrzeby kdump nie zarezerwowano jądra awaryjnego.
Netconsole uruchamiane podczas startu przetworzyło konfigurację, ale uruchomiło się przed eth0 istniało i samo się wyłączyło. Przekazywanie w przestrzeni użytkownika journalctlPrzekazywanie -to-UDP dotarło do drugiej maszyny z systemem Linux, ale również zatrzymało się bez podania ostatecznej przyczyny, gdy host się zawiesił.
Ten rezultat jest przydatny: przekazywanie w przestrzeni użytkownika nie może wysyłać komunikatów po zatrzymaniu planisty lub stosu sieciowego i nie może wygenerować ostrzeżenia jądra, które nigdy nie zostało wyemitowane. Na tym etapie debugujące jądro od dostawcy lub ukierunkowana instrumentacja są cenniejsze niż kolejny identyczny zapis z przestrzeni użytkownika.
ZimaOS 1.7.1 Zmieniono podejrzane komponenty, ale nie zostało to jeszcze zweryfikowane
Drugi użytkownik ZimaBoard 2 zgłosił powtarzające się awarie Pythona i innych procesów w pobliżu momentu zawieszenia. Zespół ZimaOS poinformował, że usunął zależność Crudini z zimaos-welcome, zmniejszono częstotliwość żądań zasobów tej usługi i zaplanowano te zmiany w wydaniu testowym.
Zespół później wyjaśnił, że problem z Crudini był tylko wyzwalaczem, a rzeczywista przyczyna awarii systemu nadal była badana. W ZimaOS 1.7.1 cofnięto również wersję Docker Engine, aby poprawić uruchamianie kontenerów i zmniejszyć prawdopodobieństwo blokowania komunikatów brokera DBus.
Ostatni post pyta, czy inny użytkownik działa stabilnie na wersji 1.7.1; nie podaje jednak wymaganego wyniku czasu działania. Nie opisuj wersji 1.7.1 jako potwierdzonej poprawki zawieszania, dopóki pierwotny warunek awarii nie pozostanie stabilny dłużej niż w poprzednim oknie czasowym.
Eskaluj, podając testy już wykluczone
Skuteczny pakiet zgłoszeniowy powinien zawierać model sprzętu, wersję ZimaOS i jądra, kontroler pamięci masowej, obciążenia, godziny awarii, aktywne parametry rozruchowe, logi z poprzedniego uruchomienia oraz listę kontrolowanych testów wraz z wynikami.
Wyraźnie zaznacz, że akceleracja GPU, izolacja Frigate, usunięcie parametrów IOMMU/VFIO, wyłączenie i915, zmiany SATA LPM, trwałe logi, pstore ani zdalne logowanie w przestrzeni użytkownika nie doprowadziły w tym przypadku do potwierdzonej naprawy.
Jeśli inny system operacyjny pozostaje stabilny przy tym samym obciążeniu, podczas gdy ZimaOS nadal się blokuje, zachowaj to porównanie i poproś o przygotowanie specjalnej kompilacji lub przeprowadzenie analizy przez dostawcę. Gdy niezawodność ma kluczowe znaczenie operacyjne, powrót do stabilnego środowiska jest uzasadnioną granicą przerwania testów, zamiast bez końca dodawać niezweryfikowane parametry.
FAQ
Czy Frigate lub Intel VAAPI powodowały awarie ZimaOS?
Wątek tego nie potwierdził. Awarie nadal występowały po wyłączeniu akceleracji GPU oraz po kolejnych testach izolacji i915.
Czy usunięcie parametrów IOMMU i VFIO naprawiło zawieszanie?
Nie. Aktywna linia poleceń potwierdziła, że oba elementy zostały usunięte, a host ponownie się zablokował.
Czy ZimaOS 1.7.1 naprawia całkowite zawieszanie się systemu?
Wydanie zmieniło Crudini, zimaos-welcome, zachowanie Docker Engine i związane z DBus, ale temat kończy się, zanim wynik testu stabilności potwierdzi odzyskanie sprawności.
