Źródło problemu wygląda na konfigurację btop, ale w rzeczywistości dotyczą go dwa różne środowiska uruchomieniowe. ZimaOS ma wbudowany panel wydajności btop od wersji v1.3.3. Niezależnie od tego użytkownicy mogą zainstalować kontener btop z App Store. Kontener zwykle widzi własną przestrzeń nazw sieciową, natomiast btop działający na hoście może widzieć interfejsy udostępnione hostowi.
To rozróżnienie wyjaśnia, dlaczego jeden z uczestników mógł przełączać się między eth0, eth1, virbr0, docker0 i kilkoma urządzeniami veth, podczas gdy btop autora pierwotnego wpisu oferował tylko lo i eth0. Wątek nie zakończył się jednak potwierdzonym rozwiązaniem problemu w dokładnie takiej konfiguracji autora wpisu.
Sam ZimaOS korzystał z interfejsu 10GbE
btop dodano jako wbudowany panel wydajności ZimaOS
IceWhale wprowadziło wbudowany panel btop w ZimaOS 1.3.3. Obecni użytkownicy nie powinni więc zakładać, że muszą zainstalować osobny kontener btop, aby uzyskać podstawowe monitorowanie systemu.
Zobacz oficjalny zakres funkcji wbudowanego btop.
Przykład btop działającego na hoście pokazywał kilka interfejsów fizycznych i wirtualnych
btop w Dockerze widzi tylko przypisaną mu przestrzeń nazw sieciową
Odpowiedzi społeczności wyjaśniały, że kontener btop z App Store może widzieć tylko sieć kontenera. To normalne zachowanie Dockera: aplikacja nie może monitorować interfejsów hosta, które nie zostały udostępnione w jej przestrzeni nazw.
Zmiana selektora interfejsu w btop nie utworzy brakującego interfejsu
Wybór sieci hosta Dockera powodował awarię lub zatrzymywał aplikację ze źródła
Autor oryginalnego wpisu napisał, że przełączenie kontenera btop z App Store na sieć hosta nie rozwiązało problemu, ponieważ btop przestał działać. Rozważał też dodanie SYS_PTRACE lub SYS_ADMIN.
Wątek nie potwierdza, że te zmiany uprawnień działają, dlatego nie należy ich zalecać wyłącznie po to, by wyświetlić jeden panel ze statystykami.
Plik binarny btop hosta istniał, ale według źródła nie działał
W wątku nie ma potwierdzonego rozwiązania końcowego
Żadna odpowiedź pracownika IceWhale w źródłowym wątku nie potwierdza, czy wbudowany btop autora wpisu był uszkodzony, miał problem związany z wcześniejszą ręczną instalacją, czy też występował w nim odrębny błąd w wersji 1.6.1.
Bezpieczniejsze rozwiązanie na teraz
- Najpierw użyj wbudowanego panelu btop w ZimaOS.
- Sprawdź, czy karta sieciowa jest dostępna, używając aktualnych narzędzi sieciowych hosta.
- Korzystając z monitora w kontenerze, pamiętaj o jego przestrzeni nazw sieciowych.
- Nie zwiększaj uprawnień do SYS_ADMIN wyłącznie na potrzeby metryk.
- Jeśli wbudowany btop nie działa, sprawdź bieżącą wersję i dokładny błąd z interfejsu wiersza poleceń zamiast wielokrotnie instalować drugi pakiet btop.
Czarny ekran btop i brak eth1 to dwa oddzielne objawy
Na początku wątku autor oryginalnego wpisu napisał, że wbudowany pulpit btop otwierał się jako czarny ekran. Później skupił się na btop z App Store/kontenera, który działał, ale wyświetlał tylko lo i eth0. Nie należy sprowadzać tych problemów do jednej przyczyny.
Błąd wbudowanego panelu może dotyczyć sesji hosta btop/ttyd, natomiast brak interfejsów hosta w monitorze Dockera wynika z oczekiwanej izolacji przestrzeni nazw.
Wysoki lub zmieniający się numer portu btop nie musi być przyczyną problemu
ZimaOS uruchamia niektóre narzędzia terminalowe w sesjach internetowych. Błąd portu lub połączenia widoczny w przeglądarce nie dowodzi, że fizyczna karta sieciowa jest źle skonfigurowana. Najpierw uruchom polecenie bezpośrednio na hoście i zapisz dokładny błąd.
Większe uprawnienia kontenera nie są darmowym rozwiązaniem problemu z monitorowaniem
Dodanie SYS_ADMIN, szerokiego dostępu do urządzeń lub pełnego trybu uprzywilejowanego może udostępnić kontenerowi znacznie więcej zasobów hosta, niż potrzebuje btop. Nawet network_mode: host zmienia model izolacji kontenera.
Do monitorowania systemu lepiej użyć działającego monitora zintegrowanego z hostem, niż nadawać kontenerowi ze sklepu z aplikacjami uprawnienia niemal takie jak na hoście tylko po to, by mógł wyświetlać wszystkie interfejsy.
Sprawdź eth1 na hoście, zanim obwinisz btop
Sprawdź bieżącą stronę sieci ZimaOS lub polecenia sieciowe hosta i potwierdź, że interfejs 10GbE jest aktywny, ma oczekiwany adres i przesyła ruch. W źródle udało się to zrobić: sam ZimaOS wyświetlał interfejs eth1 i korzystał z niego.
Jeśli sieć hosta widzi interfejs, a kontener nie, problem leży w środowisku monitorowania, a nie w sterowniku karty sieciowej.
Niedziałający wbudowany btop w obecnej wersji ZimaOS to nowa regresja
Źródło dotyczyło wersji 1.6.1, podczas gdy obecna wersja ZimaOS to 1.7.1. Jeśli wbudowany panel nadal jest dziś czarny, zapisz bieżącą wersję, architekturę procesora, bezpośredni wynik polecenia btop, błąd w konsoli przeglądarki lub sesji oraz informację, czy przywrócenie lub ponowna instalacja coś zmienia. Nie zakładaj, że wątek z kwietnia 2026 roku wyjaśnia obecną awarię.
FAQ dotyczące sieci w btop
Czy btop może wybrać eth1, jeśli eth1 nie jest widoczny w jego przestrzeni nazw?
Nie. Selektor przełącza się tylko między interfejsami widocznymi dla uruchomionego procesu.
Czy inny użytkownik potwierdził, że wbudowany btop widzi eth1?
Tak. James poinformował, że przełączał się między interfejsami eth0, eth1, libvirt, Docker i veth w btop na hoście.
Czy w źródle potwierdzono bezpieczne rozwiązanie problemu z uprawnieniami Dockera?
Nie. Omawiano sieć hosta i dodawanie możliwości, ale nie potwierdzono żadnej działającej konfiguracji.
