...

Skuteczne wykorzystanie lsof: analiza otwartych plików i procesów

Ustawiłem lsof linux , aby w ciągu kilku sekund sprawdzić, który proces utrzymuje otwarty dany plik, gniazdo lub port. W ten sposób wykrywam zablokowane logi, zajęte Porty oraz odblokowuję pliki bez zbędnych komplikacji i skutecznie usuwam usterki.

Punkty centralne

Aby ułatwić rozpoczęcie, podsumuję najważniejsze Aspekty krótko podsumowując.

  • Zasoby wyświetlać: procesy, pliki, katalogi, urządzenia, potoki, gniazda.
  • Filtry opcje: według nazwy procesu (-c), identyfikatora PID (-p), użytkownika (-u), pliku, katalogu (+d/+D), portu (-i).
  • Błąd ograniczyć: znaleźć zablokowane pliki, rozwiązać konflikty portów, zidentyfikować zawieszone usługi.
  • Sieć sprawdź: szybko zidentyfikuj aktywne połączenia i zajęte porty.
  • Przepływ pracy usprawnić: najpierw zawęzić zakres, następnie przeprowadzić ukierunkowaną analizę, a na koniec podjąć działania.

Dlaczego lsof ma znaczenie w codziennym życiu

Używam lsof, gdy usługa się nie uruchamia, plik zgłasza status „busy“ lub port jest już zajęty. Narzędzie to łączy plik, proces, użytkownika i sieć w przejrzystą Widok. Od razu widzę, który PID blokuje dostęp i od kiedy. Dzięki temu nie muszę zgadywać, tylko zamykam właściwy proces, zamiast przypadkowo zatrzymać niewłaściwą usługę. Szczególnie na serwerach produkcyjnych pozwala mi to zaoszczędzić od kilku minut do kilku godzin, ponieważ mogę bezpośrednio zidentyfikować przyczynę w samym procesie. Takie podejście ogranicza liczbę zgłoszeń, zmniejsza liczbę awarii i zapewnia niezawodność Ustalenia.

Zrozumienie podstawowej składni i wyników

Podstawowa forma brzmi lsof [opcje] i zwraca bez parametrów wszystkie aktualnie otwarte obiekty. Na systemach o dużym obciążeniu filtruję dane wyjściowe, zamiast przeglądać tysiące wierszy. Ważne jest to, że w systemie Linux pojęcie „plik“ ma szeroki zakres: obejmuje ono katalogi, urządzenia, biblioteki i siecioweGniazda. W wynikach pomocne są kolumny takie jak COMMAND, PID, USER, FD, TYPE, NAME. Najpierw zwracam uwagę na kolumny FD (deskryptor pliku), TYPE (REG, DIR, IPv4/6) oraz NAME wraz ze ścieżką lub numerem portu. Czytając te kolumny, w krótkim czasie można zrozumieć aktualny stan systemu i przejrzyście przyporządkować zasoby. Procesy.

Instalacja i uprawnienia w praktyce

W wielu dystrybucjach jest lsof nie jest preinstalowany. Dlatego instaluję go z wyprzedzeniem za pomocą menedżera pakietów (apt install lsof, dnf install lsof, yum install lsof lub pacman -S lsof), aby w razie incydentu był od razu dostępny. Aby uzyskać pełny obraz sytuacji, zazwyczaj uruchamiam lsof z opcją sudo ponieważ bez podwyższonych uprawnień wiele wpisów kończy się komunikatem „permission denied“ lub w ogóle ich brakuje. Mimo to celowo zaczynam bez uprawnień roota, sprawdzam, jak daleko uda mi się zajść, i podnoszę uprawnienia tylko wtedy, gdy jest to konieczne. W systemach z SELinuxem lub AppArmorem zwracam uwagę, że konteksty bezpieczeństwa mogą ograniczać widoczność; w zależności od kompilacji pokazuje lsof Dodaję dodatkowe konteksty. Podczas zapytań zbiorczych wyłączam ostrzeżenia za pomocą -w, aby skrypty zachowały swoją niezawodność.

Bezpieczne odczytywanie pól i typów FD

Kolumna FD to mój klucz do zrozumienia. Typowe wartości to:

  • cwd: bieżący katalog roboczy procesu.
  • txt: plik wykonywalny (segment tekstowy) procesu.
  • mem: załadowane biblioteki współdzielone i pliki odwzorowane w pamięci (mapowania pamięci).
  • 0u, 1w, 2w: Standardowe deskryptory (stdin, stdout, stderr) z trybem r (czytaj), w (zapisz) lub u (odczyt/zapis).
  • wyższe wartości, takie jak 3u, 7r: standardowe otwarte deskryptory, często pliki, gniazda lub potoki.

Z TYP czytam klasę obiektu: REG (zwykły plik), DIR (katalog), CHR/BLK (urządzenie do rysowania/blokowania), FIFO (rura), IPv4/IPv6 (sieć), UNIX (gniazdo domeny Unix). W NAZWA znajduje się ścieżka lub, w przypadku gniazd, punkt końcowy, np. TCP *:80 (LISTEN) lub UDP 127.0.0.1:123. Gdybym (usunięto) Kiedy to widzę, wiem, że plik został usunięty, ale nadal jest utrzymywany przez identyfikator PID – to typowa przyczyna „znikającego“ miejsca na dysku.

Filtrowanie według kryteriów: pliki, katalogi, porty

Najpierw określę kontekst, a potem zacznę od odpowiedniego Filtry. W przypadku katalogu używam lsof +D /var/log (rekurencyjnie) lub lsof +d /var/log (tylko sam folder). Poszczególne pliki sprawdzam bezpośrednio, na przykład lsof /var/log/syslog, aby wyświetlić procesy piszące. W przypadku portów ustawiam lsof -i:80, lsof -i:443 lub ogólnie lsof -i . Lubię to łączyć z -nP, dzięki czemu lsof nie rozdziela adresów IP i portów i działa szybciej. W ten sposób z nieprzejrzystego stanu systemu w mgnieniu oka powstaje przejrzysty Zdjęcie.

Łączenie i zawężanie filtrów

Aby zapewnić powtarzalność analiz, łączę filtry z -a połączone logicznie. W ten sposób otrzymuję tylko te wpisy, które spełniają wszystkie warunki. Przykłady:

  • lsof -a -p 1234 -d cwd,txt,mem – wyłącznie katalog roboczy, plik binarny oraz załadowane biblioteki danego procesu.
  • lsof -a -iTCP -sTCP:ESTABLISHED -p 1234 – wyłącznie nawiązane połączenia TCP o danym PID.
  • lsof -a -u www-data +d /var/www – Pliki znajdujące się w katalogu /var/www, które utrzymują otwarte procesy użytkownika www-data.

Z -d filtruję według deskryptorów (liczb lub nazw, takich jak cwd, mem). -U wyświetla mi konkretnie gniazda domenowe systemu Unix, gdy chcę zbadać lokalne problemy związane z komunikacją międzyprocesową (IPC). W ten sposób ograniczam szum i widzę dokładnie to, co ma związek z danym zagadnieniem.

Szybkie przypisywanie procesów i użytkowników

Jeśli znam nazwę usługi, to lsof -c nginx wszystkie otwarte pliki serwera WWW, w tym Biblioteki, konfiguracje i gniazda. Aby zapewnić jednoznaczną analizę, często korzystam z identyfikatora PID: lsof -p 1234 wyświetla wszystkie uchwyty konkretnego procesu. Sprawdzanie związane z użytkownikiem przeprowadzam za pomocą lsof -u mysql lub innego konta, aby uwidocznić zasoby otwarte przez konto usługowe. W przypadku bardziej szczegółowych analiz uzupełniam widok procesu o Rachunkowość procesowa i sprawdzam, jak często i jak długo programy korzystają z zasobów. To połączenie widoku procesów, użytkowników i działań pozwala mi szybko dotrzeć do sedna w przypadku skomplikowanych zjawisk Przyczyna.

Przypadki szczególne: usunięte pliki, logrotate i pliki zajmujące dużo miejsca

Gdy „brakuje“ miejsca na dysku, często znajduję przyczynę za pomocą lsof +L1: Wyświetla listę plików, które zostały już usunięte, ale są nadal utrzymywane przez uruchomione procesy. Typowymi przykładami są rotowane pliki logów, duże pliki tymczasowe lub zrzuty debugowania. Zamiast w pośpiechu powiększać partycję, celowo zamykam wyświetlone identyfikatory PID lub wysyłam standardowy sygnał do ponownego załadowania. W przypadku usług logowania preferuję czyste ponowne załadowanie danej usługi, aby deskryptory zostały ponownie otwarte. Rozwiązania awaryjne, takie jak truncate lub bezpośrednie usunięcie bez ponownego uruchamiania procesu jedynie odkłada rozwiązanie problemu na później.

W przypadku długich strumieni danych dodatkowo sprawdzam kolumnę ROZMIAR/WYŁ. (widoczne w zależności od kompilacji), aby sprawdzić, czy jakiś proces jest powiązany z bardzo dużym offsetem. To wyjaśnia, dlaczego uchwyt zajmuje tak dużo miejsca w pamięci, mimo że plik jest oznaczony jako usunięty.

Systematyczne rozwiązywanie typowych scenariuszy błędów

Usuwam zablokowane pliki po tym, jak lsof pokazał mi, jak należy postępować. Zamiast bezładnie zatrzymywać usługi, celowo zamykam proces o danym PID lub ponownie uruchamiam właśnie tę usługę. Konflikty portów rozwiązuję za pomocą lsof -i:, sprawdzam identyfikator PID procesu i odpowiednio dostosowuję port, usługę lub zaporę sieciową. Jeśli jakiś proces się zawiesza, sprawdzam jego otwarte deskryptory za pomocą lsof -p i sprawdzam, czy czeka on na plik, potok czy gniazdo. W celu przeprowadzenia dogłębnej analizy uzupełniam ten widok o strace w sposób ukierunkowany, aby na bieżąco monitorować wywołania systemowe. W ten sposób niezawodnie rozwiązuję powtarzające się usterki i dokumentuję konkretne kroki na przyszłość Incydenty.

Uwzględnienie kontenerów i przestrzeni nazw

Wyjaśnienie w kontekście środowisk kontenerowych (np. z własnymi przestrzeniami nazw sieciowymi) lsof zauważam rozbieżności między hostem a kontenerem. Uruchamiam lsof albo bezpośrednio w kontenerze, albo z poziomu hosta wchodzę do przestrzeni nazw docelowego procesu. W ten sposób rozpoznaję, dlaczego port w kontenerze znajduje się w stanie LISTEN, podczas gdy na hoście wydaje się „wolny“: znajdują się one w różnych przestrzeniach nazw. Podobnie postępuję w przypadku przestrzeni nazw montowania: montowania typu bind i systemy plików typu overlay pojawiają się w kolumnie NAME wraz ze swoimi rzeczywistymi ścieżkami i pomagają wykryć nieprawidłowo skonfigurowane woluminy. Dodatkowo porządkuję otwarte deskryptory według użytkowników i grup Cgroup, gdy steruję usługami za pomocą nadzorców lub rozwiązań do orkiestracji.

Analiza sieci za pomocą polecenia lsof -i

Z lsof -i rejestruję aktywne połączenia i nasłuchuję zajętych Porty. Filtry takie jak lsof -iTCP -sTCP:LISTEN wyświetla konkretne usługi w stanie LISTEN. W przypadku poszczególnych protokołów korzystam z lsof -iUDP lub konkretnych portów, takich jak lsof -i:25 dla serwerów pocztowych. Sprawdzam również, czy proces PID utrzymuje otwarte wiele gniazd, co może wskazywać na wycieki lub pętle bez końca. Podczas kontroli bezpieczeństwa porównuję oczekiwane usługi z wynikami i wykrywam obce lub zapomniane Usługi. Ten widok sieciowy pozwala zaoszczędzić czas, ponieważ nie muszę sprawdzać wielu narzędzi jednocześnie i widzę wszystko w jednym miejscu.

Szczegółowe informacje o sieci

W przypadku szczególnie precyzyjnych zapytań korzystam ze składni adresów i portów z -i: Ograniczam się do adresów źródłowych lub docelowych (lsof [email protected]) lub połącz adres i port (lsof [email protected]:443). Z -sTCP:ESTABLISHED widzę owocne sesje, podczas gdy -sTCP:LISTEN wyświetla tylko słuchacze. Analizy UDP wykorzystuję do uwidocznienia usług z dużą liczbą krótkotrwałych gniazd (DNS, Syslog, NTP). Sprawdzam również, czy procesy są narażone na ryzyko w sieci bardziej niż to konieczne (np. słuchacze na 0.0.0.0 (zamiast lokalnego interfejsu). Zmniejsza to późniejszy nakład pracy związany z zabezpieczaniem systemu.

Przegląd tabeli: Najczęściej wybierane opcje

Bardzo często korzystam z kilku podstawowych opcji i dostosowuję je w zależności od Scenariusz. Poniższa tabela zawiera zestawienie najważniejszych przełączników wraz z krótkim objaśnieniem i przykładem. Dzięki temu szybciej znajduję odpowiednią formę i oszczędzam sobie długich opisów pomocy. Stosuję te opcje modułowo, co pozwala mi zachować elastyczność. Kto opanuje ten podstawowy zestaw, ten rozwiąże wiele zadań za pomocą jednego wezwanie.

Opcja Cel Przykład
-i Wyświetl połączenia sieciowe i zajęte porty lsof -i:443
-c NAZWA Filtruj według nazw procesów (dopasowanie prefiksu) lsof -c nginx
-p PID Wszystkie otwarte pliki o danym PID lsof -p 1234
-u UŻYTKOWNIK Otwarte zasoby użytkownika lsof -u mysql
+d DIR Tylko wskazany katalog lsof +d /var/log
+D DIR Rekurencyjne przeszukiwanie katalogu lsof +D /var/log
-nP Brak sprawdzania nazw DNS i portów (szybsze) lsof -nP -i
-t Wyświetlaj tylko identyfikatory PID (przyjazne dla skryptów) lsof -t -i:80
+L1 Wyświetl usunięte, ale nadal otwarte pliki lsof +L1

Używam -t często w celu przekazania zmiennych PID bezpośrednio do skryptów, na przykład do zabić lub systemctl. Z +L1 wykrywam procesy, które utrzymują usunięte pliki w stanie otwartym, blokując w ten sposób miejsce na dysku. W połączeniu z -r (ponownie) zauważam zmiany w krótkich Odległości. Przeprowadzając badania etapami, unika się błędnych interpretacji i zachowuje spójność. Dzięki temu diagnoza pozostaje powtarzalna i mierzalna czysty.

Efektywne przetwarzanie wydruków

Formatuję wynik od razu, żeby szybciej uzyskać wyniki użycie. Z lsof -t -i:80 | xargs -r kill -TERM zamykam mniej więcej wszystkie procesy, które zajmują port 80. Do generowania raportów korzystam z lsof -nP -i | grep LISTEN wróć i filtruj konkretne stany. Również awk pomaga: lsof -nP | awk '{print $1,$2,$3,$9}' ogranicza widok do nazwy, PID, użytkownika i ścieżki. Dokumentuję działające jednozdaniowe polecenia i oszczędzam sobie późniejszego Wyszukiwanie według odpowiednich wzorów. Małe pomocniki, takie jak watch 'lsof -nP -i:443' pokazują zmiany na żywo i przyspieszają proces podejmowania decyzji.

Automatyzacja i wynik nadający się do analizy

W przypadku powtarzających się testów korzystam z wersji nadającej się do odczytu maszynowego pliku lsof z -F. Wybieram tylko te pola, których potrzebuję (np. proces, polecenie, użytkownik, FD, nazwa) i dalej je stabilnie analizuję. Przykłady:

  • lsof -Fn -Fp -Fc -Fu -t -i:443 – minimalistyczne pola dla skryptów, które wymagają jedynie identyfikatorów PID lub nazw.
  • lsof -Fpcun -a -iTCP -sTCP:LISTEN – Gromadzenie danych dotyczących słuchaczy i ich ukierunkowane przetwarzanie.

Z -r 2 co dwie sekundy generuję widok „na żywo“ i porównuję migawki. W potokach przetwarzania łączę zmiany (sortuj, uniq, różnica), aby wykrywać nowe lub znikające uchwyty. Celowo planuję limity czasu, aby zapytania nie zawieszały się przy dużym obciążeniu, a zadania monitorujące kończyły się poprawnie.

Najlepsze praktyki i kwestie związane z bezpieczeństwem

Rozpoczynam analizy z minimalnymi uprawnieniami i zwiększam je dopiero wtedy, gdy korzeń, jeśli brakuje mi uprawnień. W ten sposób ograniczam ryzyko i dbam o przejrzystość logów. Sprawdzam regularne skanowania za pomocą lsof -i w ramach moich przewidywanych zadań, mających na celu wykrywanie nietypowych słuchaczy lub połączeń. Podejrzane identyfikatory PID sprawdzam następnie szczegółowo, analizując pliki, biblioteki i Gniazda. W oknach konserwacyjnych dbam o to, by żadne usunięte, ale wciąż otwarte pliki nie marnowały miejsca. Kto poważnie podchodzi do kwestii bezpieczeństwa, włącza lsof do list kontrolnych i reaguje na nieprawidłowości zgodnie z ustalonymi Kroki.

Typowe przeszkody i skuteczne rozwiązania

  • Nie wszystkie wpisy są widoczne: Bez uprawnień roota często brakuje mi procesów innych użytkowników lub uchwytów związanych z jądrem. Korzystam z tego celowo sudo.
  • Powolne wyświetlanie: Wyłączam rozdzielczości za pomocą -nP, zrezygnuj z rekurencji i ogranicz za pomocą -a mocno.
  • +D za drogie: Rekurencyjne przeszukiwanie katalogów może być bardzo czasochłonne. Zaczynam od +d lub konkretnych ścieżkach i rozszerzam je dopiero w razie potrzeby.
  • Port zajęty, proces niejasny: Łączę lsof -i: -nP z -t dla PID i przejdź do lsof -p głębiej.
  • „Brakuje “wolnego” miejsca: lsof +L1 wyszukuje pliki otwarte, ale usunięte. Następnie należy celowo ponownie uruchomić lub zakończyć proces.
  • Kontenery/przestrzenie nazw: Sprawdzam zapytanie w odpowiedniej przestrzeni nazw, w przeciwnym razie widzę nieprawidłowe słuchacze lub przeoczę otwarte pliki.

Zrozumienie wydajności i ograniczeń

W przypadku bardzo dużych systemów pełne skanowanie za pomocą lsof zajmuje sporo czasu i powoduje zauważalne Obciążenie. Dlatego stosuję filtry już na wczesnym etapie i przełączam za pomocą -nP wszystkie rozstrzygnięcia. W przypadku bardzo dużej liczby transakcji sprawdzam równolegle Ograniczenia deskryptorów plików i w razie potrzeby je zwiększ. Skrypty powinny uwzględniać limity czasu i korzystać z -t Przekazuję tylko identyfikatory PID, aby ograniczyć ilość danych. Dokumentuję wyjątki i wbudowuję powtarzające się kontrole w procesy automatyzacji. Dzięki temu diagnostyka pozostaje niezawodna i przejrzysta nawet pod obciążeniem sterowalny.

Przebieg pracy w praktyce: od objawów do przyczyny

Zacznę od pytania: czy chodzi o plik, proces czy Port? Następnie wybieram odpowiedni wstęp, na przykład lsof /ścieżka/do/pliku, lsof -p lub lsof -i:. Sprawdzam pola USER, FD, TYPE i NAME oraz odnotowuję, co wydaje się zgodne z oczekiwaniami, a co jest zaskakujące. Następnie podejmuję odpowiednie działania: ponownie uruchamiam proces, dostosowuję konfigurację, zwiększam limit lub odblokowuję port. W razie wątpliwości utrwalam stan, zapisuję logi i powtarzam pomiar po wprowadzeniu zmiany. Ta procedura pozwala mi zachować koncentrację i zapewnia przejrzyste Łańcuch dowodowy.

Lista kontrolna: szybkie przepisy na co dzień

  • Kto blokuje ten plik? lsof /ścieżka/do/pliku – Odczytać kod PID, celowo ponownie uruchomić lub zakończyć proces.
  • Która usługa zajmuje ten port? lsof -nP -i: – Rozwiąż konflikt, dostosuj numer portu lub adres wiązania.
  • Gdzie znika miejsce na płyty? lsof +L1 – znaleźć otwarte i usunięte pliki, ponownie uruchomić powiązane procesy (PID).
  • Czy proces zawiesił się na operacjach wejścia/wyjścia? lsof -p – zwrócić uwagę na potoki, gniazda lub pliki; w razie potrzeby uzupełnić o strace.
  • Które odtwarzacze naprawdę działają? lsof -nP -iTCP -sTCP:LISTEN – porównać z listą oczekiwań.
  • Z jakich zasobów korzysta konto usługowe? lsof -u – Wykrywanie nieprawidłowości na poszczególnych kontach.

Podsumowanie na co dzień

lsof pokazuje mi, kto blokuje dany plik, katalog lub port. Za pomocą -c, -p, -u, +d/+D oraz -i szybko zawężam zakres poszukiwań. Odblokowuję zablokowane pliki, wykrywam konflikty portów i odkrywam nietypowe Połączenia. W połączeniu z -nP Pracuję sprawnie i dbam o to, by wyniki były przejrzyste. W celu przeprowadzenia bardziej szczegółowych analiz korzystam z dodatkowych narzędzi, dokumentuję sprawdzone jednozdaniowe skrypty i wbudowuję powtarzające się kontrole w procesy automatyzacji. Dzięki temu diagnoza za pomocą lsof pozostaje bezpośrednia, pewna i mierzalna skutecznie.

Artykuły bieżące