Użyłem jednej komendy Linuksa, aby dokładnie zobaczyć, co moje aplikacje robią z moim systemem
Wentylator w moim laptopie pracował nieco intensywniej niż zwykle przez kilka dni. Działo się tak nawet wtedy, gdy otwarte były tylko moja przeglądarka i edytor tekstu, i nic widocznego nie wydawało się tego powodować. Korzystanie z htop pokazało normalne użycie CPU i pamięci, ale wiedziałem, że coś jest nie tak.
Musiałem zobaczyć, czego menedżer zadań nie pokazywał, więc użyłem polecenia lsof. To polecenie wygenerowało żywą mapę wszystkich otwartych plików i zasobów na komputerze. Wyniki były zdumiewające i zmieniły sposób, w jaki myślę o oprogramowaniu, które uruchamiam.
Co to jest lsof
I dlaczego „list open files” jest najbardziej mylącą nazwą w Linuksie
Na Linuksie pliki to nie tylko dokumenty w folderach; mogą być też potokami międzyprocesowymi, węzłami urządzeń lub gniazdami sieciowymi. To sprawia, że lista otwartych plików w lsof jest żywą mapą wszystkiego, czego system Linux dotyka. To narzędzie jest znacznie potężniejsze, niż sugeruje jego nazwa.
Twoja standardowa instalacja Linuxa już zawiera to narzędzie; może go brakować w minimalnych instalacjach Ubuntu, Fedora lub Debian, ale można je zainstalować, wykonując jedno polecenie:
- Debian/Ubuntu:
sudo apt install lsof - Fedora/RHEL:
sudo dnf install lsof
Uruchomienie lsof generuje onieśmielający wynik, ale musisz skupić się na tych czterech kolumnach, aby cokolwiek z tego zrozumieć:
Kolumna | Co to znaczy |
|---|---|
POLECENIE | Aplikacja lub proces, który coś ma otwarte |
PID | Jego unikalny numer ID (będziesz go potrzebować, jeśli chcesz podjąć działania) |
TYP | Jakiego rodzaju zasób ma otwarty (zwykły plik, gniazdo sieciowe, potok czy urządzenie) |
|
IMIĘ | Konkretna ścieżka pliku, adres IP lub port, którego dotyka |
Na macOS uruchomienie lsof z użyciem sudo ujawnia procesy poza aktualnym użytkownikiem, chociaż niektóre demony systemowe pozostają niedostępne z powodu zabezpieczeń macOS.
Polecenia, które uruchomiłem
W kolejności, w jakiej faktycznie je przeprowadziłem, w tym tej, która mnie zatrzymała
Zacząłem od uruchamiania szerokich poleceń lsof i stopniowo je zawężałem:
Po pierwsze:
lsof -i
Pokazuje aktualną listę procesów z aktywnymi połączeniami sieciowymi. Uruchomienie go z sudo pokazuje procesy poza bieżącym użytkownikiem, w tym demony działające w tle. Wyniki, które widziałem, wydawały się znacznie większe niż się spodziewałem dla bezczynnej maszyny.
Drugi:
lsof -p $(pgrep -d',' process_name)Dzięki temu poleceniu możesz zobaczyć wszystko, co dana aplikacja ma aktualnie otwarte. pgrep -d',' nazwa_procesu znajduje i formatuje identyfikatory procesów aplikacji dla lsof.
Upewnij się, że aplikacja działa, gdy uruchamiasz polecenie; w przeciwnym razie lsof wyrzuci błąd, ponieważ pgrep nie zwróci żadnej wartości.
Trzeci:
lsof -i :443Szyfrowany ruch HTTPS używa portu 443. Uruchomienie powyższego polecenia pokazuje procesy aktywnie wykonujące szyfrowane połączenia wychodzące. Był to kolejny punkt, gdzie zobaczyłem więcej wpisów, niż się spodziewałem, gdy uruchomiłem je mając otwarte tylko przeglądarkę i edytor tekstu.
Czwarty:
lsof +D /home/afamTo polecenie ujawniło wszystkie procesy aktywnie korzystające z plików w moim katalogu domowym. Dodanie +D pozwala na przeszukiwanie rekurencyjne wszystkich podkatalogów, ale oznacza to również, że polecenie może działać wolniej. Mała litera +d daje tylko katalog najwyższego poziomu. Większość wyników, które otrzymałem, była oczekiwana, ale jeden mnie zaskoczył.
Co właściwie działało na moim komputerze
Jedna rzecz była nieszkodliwa, jednej rzeczy nie mogłem wytłumaczyć
Fałszywy alarm — gniazdka w stanie TIME_WAIT
Zaobserwowałem kilka połączeń pokazujących stan TIME_WAIT, co skłoniło mnie do myślenia, że coś się zawiesiło, ale się myliłem. TIME_WAIT jest normalny na końcówce, która zamknęła połączenie: gniazda pozostają chwilowo, aby odprowadzić zbłąkane pakiety i uniknąć kolizji portów. Tak więc, nawet jeśli wygląda to alarmująco w wynikach lsof, jest to oczekiwane i tymczasowe zjawisko.
Prawdziwe zaskoczenie — mój edytor tekstu łączący się z domem
lsof -i :443 pokazało, że mój edytor tekstu utrzymywał wychodzące połączenie HTTPS, nawet gdy myślałem, że jest bezczynny. IP rozwiązało się do dostawcy infrastruktury w chmurze w celu telemetrii i sprawdzania aktualizacji rozszerzeń. To nie było złośliwe, ale przed tym testem nie miałem pojęcia, że działa on według własnego harmonogramu.
Ten, z którym się identyfikujemy — przeglądarka, która nigdy się w pełni nie zamyka
lsof -p pokazało, że moja przeglądarka miała otwarte deskryptory plików, a nawet po jej zamknięciu przynajmniej dwa gniazda sieciowe pozostały otwarte. Wygląda na to, że jest to powszechna praktyka w przypadku przeglądarek, ponieważ jest to ważne dla powiadomień i aktualizacji.
Chociaż wszystkie te dane były dobre do obserwacji, powinieneś zrozumieć, że lsof ma ograniczenia. Najbardziej zauważalne jest to, że chociaż pokazuje otwarte połączenie i dokąd zmierza, nie ujawnia, jakie dane przez nie przechodzą. Do zobaczenia zawartości ruchu potrzebne byłoby inne narzędzie.
Co możesz zrobić z wynikiem
Dzięki poziomowi szczegółowości, jaki ujawnia lsof, jaki powinien być Twój następny krok? Cóż, masz kilka opcji. Pierwszą jest sprawdzenie nieznanego połączenia. Uruchom whois na adresie skopiowanym z kolumny NAME. Zauważyłem, że wiele nieoczekiwanych adresów zazwyczaj prowadzi do AWS, Google Cloud, Akamai lub innych popularnych dostawców infrastruktury. Jednak bardziej przydatne jest zbadanie nazwy procesu, gdy jest ona nieznana.
Możesz również zdecydować się na monitorowanie przez dłuższy czas, ponieważ pojedynczy wynik może nie opowiadać całej historii. Uruchomienie polecenia takiego jak watch -n 2 lsof -i daje w tym celu na żywo podgląd. Ale w niektórych przypadkach powinieneś bezpiecznie zatrzymać proces za pomocą polecenia kill PID.
Opcjonalnie możesz użyć narzędzia strace w systemie Linux. strace jest uzupełnieniem lsof: śledzi wywołania systemowe i zachowanie programu w czasie działania, zamiast wyświetlać listę otwartych zasobów.







