Vai al contenuto 
Ho impostato lsof su Linux per vedere in pochi secondi quale processo mantiene aperto un determinato file, socket o porta. In questo modo riesco a individuare i log bloccati, quelli occupati Porti e i file bloccati senza giri di parole, risolvendo i problemi in modo mirato.
Punti centrali
Per facilitare l'approccio, riassumo i punti più importanti Aspetti In breve.
- Risorse Rendere visibili: processi, file, directory, dispositivi, pipe, socket.
- Filtri utilizzare: in base al nome del processo (-c), al PID (-p), all'utente (-u), al file, alla directory (+d/+D), alla porta (-i).
- Errore restringere il campo: individuare i file bloccati, risolvere i conflitti tra porte, identificare i servizi bloccati.
- Rete Verifica: identifica rapidamente le connessioni attive e le porte occupate.
- Flusso di lavoro ottimizzare: prima restringere il campo, poi verificare in modo mirato, infine agire.
Perché lsof è importante nella vita di tutti i giorni
Uso lsof, quando un servizio non si avvia, un file segnala „occupato“ o una porta è già occupata. Lo strumento mette in relazione file, processo, utente e rete in una chiara Vista. Riconosco immediatamente quale PID sta bloccando l'accesso e da quanto tempo. In questo modo agisco invece di tirare a indovinare e termino il processo corretto, invece di arrestare per errore il servizio sbagliato. Soprattutto sui server di produzione, questo mi fa guadagnare da minuti a ore, perché identifico la causa direttamente a livello di processo. Questo approccio riduce il numero di ticket, limita i tempi di inattività e garantisce una maggiore affidabilità Risultati.
Comprendere la sintassi di base e l'output
La forma base è la seguente: lsof [opzioni] e restituisce, senza parametri, tutte le finestre attualmente aperte oggetti. Su sistemi sottoposti a carico elevato, filtro l'output invece di dover esaminare migliaia di righe. È importante sottolineare che in Linux il termine „file“ ha un significato ampio: comprende directory, dispositivi, librerie e rete-Prese. Nell'output sono utili colonne come COMMAND, PID, USER, FD, TYPE, NAME. Per prima cosa concentro la mia attenzione su FD (descrittore di file), TYPE (REG, DIR, IPv4/6) e NAME con il percorso o l’indicazione della porta. Chi legge queste colonne comprende in breve tempo lo stato attuale del sistema e assegna le risorse in modo ordinato Processi.
Installazione e autorizzazioni nella pratica
In molte distribuzioni è lsof Non è preinstallato. Lo installo quindi tempestivamente tramite il gestore di pacchetti (apt install lsof, dnf install lsof, yum install lsof oppure pacman -S lsof), in modo che sia immediatamente disponibile in caso di incidente. Per avere una visione completa, di solito eseguo lsof con sudo perché senza privilegi elevati molte voci finiscono con „permission denied“ o mancano del tutto. Comincio comunque consapevolmente senza root, verifico fino a che punto riesco ad arrivare e elevo i privilegi solo se necessario. Nei sistemi con SELinux o AppArmor tengo presente che i contesti di sicurezza possono limitare la visibilità; a seconda della build, mostra lsof Aggiungo ulteriori contesti. Nelle query di massa sopprimo gli avvisi con -w, affinché gli script rimangano robusti.
Lettura sicura dei campi e dei tipi FD
La colonna FD è la mia chiave di lettura. I valori più comuni sono:
cwd: directory di lavoro corrente del processo.txt: il file eseguibile (segmento di testo) del processo.mem: librerie condivise caricate e file mappati (memory mapping).0u,1w,2w: Descrittori standard (stdin, stdout, stderr) con modalitàr(leggi),w(scrivere) oppureu(lettura/scrittura).- cifre più elevate come
3u,7r: descrittori aperti standard, spesso file, socket o pipe.
Da TIPO leggo la classe dell'oggetto: REG (file normale), DIR (Elenco), CHR/BLK (dispositivo di disegno/blocco), FIFO (tubo), IPv4/IPv6 (rete), UNIX (Unix Domain Socket). In NOME è indicato il percorso o, nel caso dei socket, l'endpoint, ad esempio. TCP *:80 (LISTEN) oppure UDP 127.0.0.1:123. Se io (cancellato) Alla fine, mi rendo conto che un file è stato rimosso, ma è ancora trattenuto da un PID: un motivo tipico per cui lo spazio su disco sembra „scomparso“.
Filtraggio mirato: file, directory, porte
Per prima cosa definisco il contesto e poi inizio con un'introduzione adeguata Filtri. Per una directory utilizzo lsof +D /var/log (ricorsivo) oppure lsof +d /var/log (solo la cartella stessa). I singoli file li controllo direttamente, ad esempio lsof /var/log/syslog, per visualizzare i processi in scrittura. Per le porte imposto lsof -i:80, lsof -i:443 oppure in senso generico lsof -i uno. Mi piace abbinarlo a -nP, in modo che lsof non risolva indirizzi IP e porte e funzioni più velocemente. In questo modo, da uno stato del sistema poco chiaro si ottiene in pochissimo tempo una visione chiara Immagine.
Combinare e affinare i filtri
Per ottenere analisi ripetibili, combino i filtri con -a collegate logicamente. In questo modo ottengo solo i risultati che soddisfano tutte le condizioni. Esempi:
lsof -a -p 1234 -d cwd,txt,mem– solo la directory di lavoro, il file binario e le librerie caricate di un processo.lsof -a -iTCP -sTCP:ESTABLISHED -p 1234– solo le connessioni TCP attive di un determinato PID.lsof -a -u www-data +d /var/www– File presenti nella directory /var/www che mantengono attivi i processi dell'utente www-data.
Con -d filtro in base ai descrittori (numeri o nomi come cwd, mem). -U Mi mostra in modo mirato i socket di dominio Unix nell'output quando voglio analizzare problemi di IPC locale. In questo modo riduco il rumore e vedo esattamente ciò che è rilevante per la questione.
Assegnare rapidamente processi e utenti
Se conosco il nome di un servizio, mi fornisce lsof -c nginx tutti i file aperti del server web, compresi Biblioteche, configurazioni e socket. Per un'analisi chiara, lavoro spesso con il PID: lsof -p 1234 mostra tutti gli handle di un determinato processo. Le verifiche relative all'utente le eseguo con lsof -u mysql o un altro account, per rendere visibili le risorse aperte da un account di servizio. Nelle analisi più approfondite integro la vista dei processi con Contabilità di processo e vedo così con quale frequenza e per quanto tempo i programmi utilizzano le risorse. Questa combinazione di viste relative a processi, utenti e attività mi permette di arrivare rapidamente alla soluzione in caso di fenomeni complessi Causa.
Casi particolari: file cancellati, Logrotate e file che occupano molto spazio
Quando „manca“ spazio su disco, spesso ne individuo la causa con lsof +L1: Elenca i file che sono già stati cancellati, ma che vengono ancora mantenuti aperti da alcuni processi. Si tratta in genere di log ruotati, file temporanei di grandi dimensioni o dump di debug. Invece di aumentare frettolosamente le dimensioni della partizione, chiudo in modo mirato i PID visualizzati oppure invio il solito segnale di ricaricamento. Per i servizi di log preferisco eseguire un ricaricamento pulito del servizio in questione, in modo che i descrittori vengano riaperti. Soluzioni di ripiego come truncate oppure la rimozione diretta senza riavviare il processo non fa altro che rimandare il problema.
In caso di flussi di dati lunghi, controllo anche la colonna SIZE/OFF (visibile a seconda della build), per verificare se un processo è associato a un offset molto grande. Questo spiega perché un handle occupi così tanto spazio di memoria, nonostante il file sia contrassegnato come cancellato.
Risolvere in modo sistematico i tipici scenari di errore
Elimino i file bloccati dopo aver lsof mi ha mostrato il processo responsabile. Invece di arrestare i servizi a casaccio, chiudo in modo mirato il PID oppure riavvio proprio quel servizio. Risolvo i conflitti di porta con lsof -i:, controllo il PID associato e poi modifico la porta, il servizio o il firewall di conseguenza. Se un processo si blocca, ne controllo i descrittori aperti con lsof -p e verificare se sta aspettando un file, un pipe o un socket. Per analisi più approfondite, integro la visualizzazione con strace mirato, per monitorare in tempo reale le chiamate di sistema. In questo modo risolvo in modo affidabile i malfunzionamenti ricorrenti e documento i passaggi da seguire per il futuro Incidenti.
Tenere conto dei container e degli spazi dei nomi
Spiegato in contesti containerizzati (ad esempio con spazi dei nomi di rete dedicati) lsof mi capita di riscontrare incongruenze tra l'host e il container. Eseguo il comando lsof direttamente all'interno del container oppure accedo allo spazio dei nomi del processo di destinazione dall'host. In questo modo capisco perché una porta nel container sia nello stato LISTEN, mentre sull'host appare „libera“: si trovano in spazi dei nomi diversi. Procedo in modo simile con i namespace di mount: i bind mount e i file system overlay compaiono nella colonna NAME con i loro percorsi reali e aiutano a individuare i volumi configurati in modo errato. Inoltre, ordino i descrittori aperti per utente e Cgroup quando gestisco i servizi tramite supervisori o soluzioni di orchestrazione.
Analisi della rete con lsof -i
Con lsof -i rilevo le connessioni attive e ascolto quelle occupate Porti. Filtri come lsof -iTCP -sTCP:LISTEN Elenca in modo mirato i servizi nello stato LISTEN. Per i singoli protocolli utilizzo lsof -iUDP o porte specifiche come lsof -i:25 per i server di posta. Verifico inoltre se un PID mantiene aperti più socket, il che può indicare la presenza di perdite o di cicli infiniti. Nei controlli di sicurezza confronto i servizi previsti con l'output e individuo quelli estranei o dimenticati Servizi. Questa panoramica della rete mi fa risparmiare tempo, perché non devo consultare più strumenti contemporaneamente e vedo tutto in un unico posto.
Approfondire i dettagli della rete
Per le query particolarmente mirate utilizzo la sintassi di indirizzi e porte di -i: Limito la ricerca agli indirizzi di origine o di destinazione (lsof [email protected]) oppure combina indirizzo e porta (lsof [email protected]:443). Con -sTCP:ESTABLISHED vedo sessioni produttive, mentre -sTCP:LISTEN che restituisce solo i listener. Utilizzo le analisi UDP per individuare i servizi con molti socket di breve durata (DNS, Syslog, NTP). Verifico inoltre se i processi sono esposti in rete più del necessario (ad es. listener su 0.0.0.0 (anziché un'interfaccia locale). Ciò riduce il carico di lavoro necessario per l'hardening in una fase successiva.
Panoramica della tabella: opzioni più comuni
Utilizzo pochissime opzioni di base con grande regolarità e le amplio a seconda delle Scenario. La tabella seguente raccoglie i comandi più importanti, corredati da una breve spiegazione e da un esempio. In questo modo riesco a trovare più rapidamente la forma giusta e mi risparmio lunghe consultazioni della guida. Utilizzo queste opzioni in modo modulare, mantenendo così la massima flessibilità. Chi padroneggia questo insieme di comandi di base è in grado di risolvere molti compiti con un solo appello.
| Opzione | Scopo | Esempio |
|---|---|---|
| -i | Visualizza le connessioni di rete e le porte occupate | lsof -i:443 |
| -c NOME | Filtra per nome del processo (corrispondenza del prefisso) | lsof -c nginx |
| -p PID | Tutti i file aperti associati a un PID | lsof -p 1234 |
| -u UTENTE | Risorse disponibili di un utente | lsof -u mysql |
| +d DIR | Solo la directory specificata | lsof +d /var/log |
| +D DIR | Percorrere la directory in modo ricorsivo | lsof +D /var/log |
| -nP | Nessuna ricerca di DNS e nomi di porta (più veloce) | lsof -nP -i |
| -t | Visualizza solo i PID (ottimizzato per gli script) | lsof -t -i:80 |
| +L1 | Visualizza i file cancellati ma ancora aperti | lsof +L1 |
Uso -t spesso per passare i PID direttamente negli script, ad esempio a uccidere oppure systemctl. Con +L1 trovo i processi che mantengono aperti i file cancellati, occupando così spazio di archiviazione. In combinazione con -r (ripeto) noto dei cambiamenti in brevi Distanze. Effettuando i test in modo graduale, si evitano interpretazioni errate e si lavora in modo coerente. In questo modo la diagnosi rimane riproducibile e misurabile chiaro.
Elaborare l'output in modo efficiente
Formatto subito l'output in modo da ottenere i risultati più rapidamente utilizzo. Con lsof -t -i:80 | xargs -r kill -TERM chiudo tutti i processi che occupano la porta 80. Per i report utilizzo lsof -nP -i | grep LISTEN torno indietro e filtro in modo mirato gli stati. Anche awk aiuta: lsof -nP | awk '{print $1,$2,$3,$9}' limita la visualizzazione a nome, PID, utente e percorso. Documento le righe singole che funzionano e mi risparmio così di doverlo fare in seguito Ricerca secondo modelli adatti. Piccoli aiutanti come watch 'lsof -nP -i:443' mostrano i cambiamenti in tempo reale e consentono di prendere decisioni più rapidamente.
Automazione e output analizzabile
Per i controlli ricorrenti utilizzo il formato leggibile da macchina di lsof con -F. Seleziono solo i campi che mi servono (ad es. processo, comando, utente, FD, nome) e continuo ad analizzarli in modo coerente. Esempi:
lsof -Fn -Fp -Fc -Fu -t -i:443– campi minimalisti per gli script che richiedono solo i PID o i nomi.lsof -Fpcun -a -iTCP -sTCP:LISTEN– Raccogliere i dati degli ascoltatori ed elaborarli in modo mirato.
Con -r 2 genero una visualizzazione „in tempo reale“ ogni due secondi e confronto le istantanee. Nelle pipeline unisco le modifiche (ordinare, uniq, diff), per individuare gli handle nuovi o in via di eliminazione. Prevedo intenzionalmente dei timeout affinché le query non rimangano bloccate in caso di carico elevato e i processi di monitoraggio si concludano correttamente.
Migliori pratiche e aspetti relativi alla sicurezza
Avvio le analisi con diritti minimi e li aumento solo se necessario radice, se mi mancano le autorizzazioni. In questo modo riduco i rischi e mantengo chiari i log. Verifico che vengano eseguite scansioni regolari con lsof -i a fronte dei servizi che mi aspetto di fornire, al fine di individuare listener o connessioni insolite. Successivamente, esamino in modo mirato i PID sospetti attraverso file, librerie e Prese. Durante le finestre di manutenzione mi assicuro che nessun file cancellato, ma ancora aperto, occupi spazio inutilmente. Chi prende sul serio la sicurezza integra lsof nelle liste di controllo e reagisce alle anomalie con procedure prestabilite Passi.
Ostacoli comuni e soluzioni efficaci
- Non tutte le voci sono visibili: Senza i permessi di root, spesso mi mancano i processi di altri utenti o gli handle legati al kernel. Utilizzo in modo mirato
sudo. - Output lento: Disattivo le risoluzioni con
-nP, evita la ricorsione e limita con-acon forza. - +D troppo costoso: Le iterazioni ricorsive sulle directory possono essere molto lunghe. Comincio con
+doppure percorsi specifici, ampliandoli solo se necessario. - Porta occupata, processo non chiaro: Combino
lsof -i: -nPcon-tper il PID e vado sulsof -ppiù in profondità. - „Manca spazio “libero”:
lsof +L1Trova i file aperti ma cancellati. Successivamente, riavvia o chiudi il processo in modo mirato. - Contenitori/Spazi dei nomi: Controllo la query nel namespace corretto, altrimenti vedo listener errati o mi sfuggono i file aperti.
Comprendere le prestazioni e i limiti
Su sistemi di grandi dimensioni, un’acquisizione completa con lsof richiede tempo e genera un rallentamento percepibile Carico. Per questo motivo applico i filtri sin dall'inizio e passo a -nP tutte le risoluzioni. In caso di numeri di handle molto elevati, controllo parallelamente il Limiti dei descrittori di file e, se necessario, aumentale. Gli script dovrebbero prevedere dei timeout e utilizzare -t Trasmetto solo i PID per mantenere ridotte le quantità di dati. Documento le eccezioni e integro controlli ricorrenti nelle automazioni. In questo modo la diagnosi rimane affidabile e chiara anche sotto carico controllabile.
Flusso di lavoro pratico: dal sintomo alla causa
Comincio con una domanda: si tratta di un file, di un processo o Porto? Dopodiché scelgo l'introduzione più adatta, ad esempio lsof /percorso/del/file, lsof -p oppure lsof -i:. Controllo USER, FD, TYPE e NAME e prendo nota di ciò che mi sembra prevedibile e di ciò che mi sorprende. Poi intervengo: riavvio il processo, modifico la configurazione, aumento il limite o sblocco la porta. In caso di incertezza, blocco lo stato, salvo i log e ripeto la misurazione dopo aver apportato la modifica. Questo processo mi aiuta a rimanere concentrato e fornisce un quadro chiaro Catena probatoria.
Lista di controllo: ricette veloci per tutti i giorni
- Chi sta bloccando il file?
lsof /percorso/del/file– Leggere il PID, riavviare o terminare il processo in modo mirato. - Quale servizio occupa la porta?
lsof -nP -i:– Risolvere il conflitto, modificare la porta o l'indirizzo Bind. - Dove sta sparendo lo spazio per i dischi?
lsof +L1– individuare i file aperti e quelli cancellati, riavviare i PID coinvolti. - Il processo è bloccato a causa dell'I/O?
lsof -p– prestare attenzione a pipe, socket o file; se necessario, integrare con strace. - Quali listener sono effettivamente in esecuzione?
lsof -nP -iTCP -sTCP:LISTEN– confrontare con l'elenco delle aspettative. - Quali risorse utilizza un account di servizio?
lsof -u– Individuare anomalie per ogni account.
Sintesi per la vita quotidiana
lsof mi mostra chi sta bloccando quale file, quale directory o quale porta. Con -c, -p, -u, +d/+D e -i limito rapidamente il campo visivo. Sblocco i file bloccati, individuo i conflitti tra porte e rilevo anomalie Connessioni. In combinazione con -nP Lavoro in modo efficiente e mantengo i risultati chiari e comprensibili. Per analisi più approfondite integro strumenti aggiuntivi, documento le righe di codice che funzionano e incorporo controlli ricorrenti nelle automazioni. In questo modo, la diagnosi con lsof rimane diretta, affidabile e misurabile efficace.
