Use lsof to list open files and the processes holding them. For example, a responder can identify which process is using a log file, network socket or deleted file that still remains open. That helps trace suspicious activity, confirm service behaviour and troubleshoot locked resources.
What lsof shows in a real troubleshooting workflow
lsof is most useful when you need to answer a concrete operational question: “what still has this file, socket, or device open?” In practice, that makes it a fast way to connect a resource to the live process using it, especially when the name on disk no longer tells the whole story. Responder teams and operators use it to map activity back to the exact process before they decide whether to restart, isolate, or kill it.
That matters because open-file state is often the hidden reason a service behaves oddly. A log can keep growing because multiple processes write to it, a deleted file can continue consuming disk space until the last handle closes, and a port may stay bound even after a service appears to have stopped. lsof gives you a live view of those relationships instead of forcing you to infer them from static configuration.
For example, if an application is suspected of touching a sensitive log or temporary file, the useful question is not just “does the file exist?” but “which PID has it open, and under what user context?” That answer helps you determine whether the behaviour is expected, whether a stale handle is blocking clean-up, and whether the process deserves closer inspection.
How responders use lsof to confirm behaviour
In incident response and systems troubleshooting, lsof is often paired with a narrow filter so the operator can work from a known path, port, or process name. The point is to reduce noise and identify the owning process quickly, then pivot to process lineage, command line, and runtime context. When the output shows a deleted file that is still open, that can explain why disk usage does not drop even after cleanup.
It is also useful for network-facing checks. A listener on an unexpected port can reveal a forgotten service, a duplicate instance, or a process that never released the socket after a crash. In that sense, lsof is less about finding files in the abstract and more about proving which running workload is holding a resource at a specific moment.
A practical rule is to treat the output as a starting point, not the final verdict. The command tells you ownership and open-state, but you still need to validate whether the process is legitimate, whether the file descriptor pattern is normal for that service, and whether the behaviour aligns with the change window or the incident timeline.
When lsof is most valuable and where it can mislead
lsof is strongest when the issue involves a live handle, lock, or socket rather than a static file path. It is especially handy for locked resources, orphaned handles, and deleted-but-open files because those problems are invisible to ordinary file browsing. It is weaker when you need historical evidence, because it reflects the current state of the system at the moment you run it.
That means timing matters. If a process has already exited, the evidence is gone. If a file is opened and closed quickly, a single snapshot may miss it. For that reason, operators often run lsof alongside process monitoring, audit logs, and service status checks so they can separate a transient event from a persistent condition.
Another limitation is interpretation. A busy server may legitimately have many open descriptors, and not every open handle is suspicious. The real value comes from comparing what you see with the service’s normal behaviour, then deciding whether the ownership, location, or timing looks out of profile.
Risk and Threat Considerations
lsof can expose security-relevant activity because open files, sockets, and deleted resources often reveal what a process is touching right now. That is useful for defenders, but it also means the same visibility can surface suspicious processes, unexpected network listeners, or leftover access to files that should no longer be in use.
Failure mechanism: A process retains an open handle after a file is deleted, or continues listening on a socket that should have been released, so the system state no longer matches the administrator’s expectation. In an incident, that gap can hide persistence, delayed cleanup, or resource exhaustion until someone inspects the live descriptors.
Impact: Operators may misjudge whether a service has stopped, whether disk space has truly been reclaimed, or whether a suspicious process still has access to a resource. In a compromise scenario, that can slow containment, obscure malicious activity, or leave sensitive data reachable longer than intended.
Practitioner Guidance
What to verify: Confirm the owner, PID, command line, and path before acting on the output. If the process is attached to an unexpected file, port, or deleted resource, validate whether that behaviour is normal for the service rather than assuming the handle itself is malicious.
Decision rule: If the open resource explains the symptom, fix the owning process first, then clean up the file or socket state. If the handle points to an unexpected service, treat it as an investigation lead and preserve the surrounding process evidence before restarting anything.
Practitioner takeaway: The best use of lsof is to turn an ambiguous resource problem into a process ownership question, because once you know which process still holds the handle, the next step becomes a judgement about legitimacy, containment, or cleanup.