Źródło wygląda jak problem z konfiguracją btop, ale w rzeczywistości łączy dwa różne środowiska wykonawcze. ZimaOS ma wbudowany panel wydajności btop od wersji v1.3.3. Niezależnie od tego użytkownicy mogą zainstalować kontener btop ze Sklepu aplikacji. Kontener zwykle widzi własną przestrzeń nazw sieciowej, podczas gdy btop hosta 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, a także kilka interfejsów: veth interfejsy, podczas gdy btop autora oryginalnego wpisu oferował tylko lo i eth0. Wątek nadal nie zakończył się potwierdzoną naprawą dokładnie tej konfiguracji autora wpisu.
Sam ZimaOS korzystał z interfejsu 10GbE
btop został dodany jako wbudowany panel wydajności ZimaOS
IceWhale wprowadziło wbudowany panel btop do monitorowania wydajności w ZimaOS 1.3.3. Obecni użytkownicy nie powinni więc zakładać, że muszą instalować osobny kontener btop tylko po to, aby uzyskać podstawowe monitorowanie systemu.
Zobacz oficjalne informacje o zakresie funkcji wbudowanego btop.
Przykład btop hosta pokazywał wiele fizycznych i wirtualnych interfejsów
btop w Dockerze widzi tylko przestrzeń nazw sieciową, która została mu przydzielona
Odpowiedzi społeczności wyjaśniały, że kontener btop ze Sklepu aplikacji może widzieć tylko własną 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 btop nie może utworzyć brakującego interfejsu
Wybranie sieci hosta Dockera spowodowało awarię aplikacji źródłowej lub jej zatrzymanie
Autor oryginalnego wpisu stwierdził, że przełączenie kontenera btop ze Sklepu aplikacji na sieć hosta nie rozwiązało problemu, ponieważ btop przestał działać. Rozważał również dodanie SYS_PTRACE lub SYS_ADMIN.
Wątek nie potwierdza poprawności tych zmian uprawnień, dlatego nie należy ich zalecać wyłącznie po to, aby udostępnić jeden panel statystyk.
Plik binarny btop hosta istniał, ale źródło stwierdzało, że nie działał
Wątek nie zawiera potwierdzonego ostatecznego rozwiązania
Żadna odpowiedź pracownika IceWhale w źródle nie ustala, czy wbudowany btop autora wpisu był uszkodzony, dotknięty wcześniejszą ręczną instalacją, czy też napotykał osobny błąd w wersji 1.6.1.
Bezpieczniejsze podejście na dziś
- Najpierw użyj wbudowanego panelu btop w ZimaOS.
- Potwierdź istnienie karty sieciowej za pomocą bieżących narzędzi sieciowych hosta.
- Jeśli używasz monitorowania w kontenerze, poznaj jego przestrzeń nazw sieciowej.
- Unikaj eskalowania uprawnień do trybu uprzywilejowanego lub SYS_ADMIN wyłącznie na potrzeby metryk.
- Jeśli wbudowany btop nie działa, zbierz bieżącą wersję i bezpośredni błąd CLI, zamiast wielokrotnie instalować drugi pakiet btop.
Czarny panel btop i brak eth1 to dwa odrębne objawy
Na początku wątku autor oryginalnego posta napisał, że wbudowany pulpit btop otwierał się jako czarny ekran. Później skupił się na btop uruchomionym w kontenerze lub aplikacji ze Sklepu, który działał, ale pokazywał tylko lo i eth0. Tych kwestii nie należy sprowadzać do jednej przyczyny.
Niedziałający wbudowany panel może dotyczyć sesji btop/ttyd na hoście, podczas gdy brak interfejsów hosta w monitorze Dockera jest oczekiwanym skutkiem izolacji przestrzeni nazw.
Wysoki lub zmieniający się port btop nie jest automatycznie przyczyną problemu
ZimaOS uruchamia niektóre narzędzia terminalowe za pośrednictwem sesji internetowych. Wyświetlenie błędu portu lub połączenia w przeglądarce nie dowodzi, że fizyczny interfejs sieciowy jest źle skonfigurowany. Najpierw uruchom polecenie bezpośrednio na hoście i zapisz dokładny błąd.
Większe uprawnienia kontenera nie są bezkosztowym rozwiązaniem problemu monitorowania
Dodawanie SYS_ADMIN, szeroki dostęp do urządzeń lub pełny tryb uprzywilejowany mogą udostępnić znacznie większą część hosta, niż potrzebuje btop. Nawet network_mode: host zmienia model izolacji kontenera.
W przypadku telemetrii systemowej działający monitor zintegrowany z hostem jest lepszym rozwiązaniem niż nadawanie kontenerowi ze Sklepu z aplikacjami uprawnień niemal na poziomie hosta tylko po to, aby mógł wyświetlać każdy interfejs.
Zweryfikuj eth1 na hoście, zanim obwinisz btop
Sprawdź bieżącą stronę sieciową ZimaOS lub polecenia sieciowe hosta i potwierdź, że interfejs 10GbE jest aktywny, ma oczekiwany adres i przesyła dane. W źródle udało się to zrobić: samo ZimaOS wyświetlało ten interfejs i z niego korzystało eth1.
Jeśli sieć hosta widzi interfejs, ale kontener go nie widzi, granicą jest środowisko monitorowania, a nie sterownik karty sieciowej.
Potraktuj niedziałający wbudowany btop w aktualnym ZimaOS jako nową regresję
Ź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 btop wynik, błąd w konsoli/przez sesję przeglądarki oraz informację, czy odzyskiwanie lub ponowna instalacja coś zmienia. Nie zakładaj, że wątek z kwietnia 2026 roku już wyjaśnia bieżącą awarię.
Najczęściej zadawane pytania 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 narzędziu btop na hoście.
Czy źródło potwierdziło bezpieczne rozwiązanie problemu z uprawnieniami Dockera?
Nie. Omawiano sieciowanie hosta i dodatkowe uprawnienia, ale nie zweryfikowano żadnej ostatecznej, działającej konfiguracji.
