Hey there, let's break this down clearly for you—first the core differences between lsof and netstat, then why you ran into that odd discrepancy with your 8086 port.

lsof vs netstat: What’s the Difference? #

These two tools look similar at first glance, but they’re built for distinct jobs:

• lsof (List Open Files)：Linux treats everything as a file—including network sockets. This tool’s whole focus is on listing files actively opened by processes. When you run lsof -i:8086, you’re asking it to find the socket file tied to port 8086, plus the process holding that file open. It’s process-centric.
• netstat (Network Statistics)：This tool is all about the network stack itself. It pulls data directly from the kernel’s connection tables, showing active connections, listening ports, routing info, and more—regardless of whether there’s a process actively attached to them. It’s network-state-centric.

Here are the key practical distinctions:

1. Data Source:
   • lsof checks process file descriptors and kernel file system structures. If no process is attached to a port/socket, it won’t show up.
   • netstat reads from kernel TCP/UDP connection tables. It’ll display ports even if the original process has exited and the socket is in a lingering state.
2. Primary Use Case:
   • Use lsof when you need to answer: "Which process is using this port/file?" It gives you PID, process name, and owner details.
   • Use netstat when you need to see: "What’s the state of all network connections?" It’s perfect for spotting lingering connections or listening ports without active processes.
3. Permissions:
   • lsof requires root privileges to view files opened by all system processes. Regular users only see their own processes’ open files.
   • netstat lets regular users view most connection details, but you need root to see the PID associated with a port (via the -p flag).

Why lsof Didn’t Find Port 8086, But netstat Did? #

In your scenario, this almost always means the port is tied to a socket with no active process attached to it. Two common causes:

1. TIME_WAIT Connection State:
   When a TCP connection closes properly, it enters the TIME_WAIT state (usually a few minutes, based on 2x the maximum segment lifetime). During this time, the kernel reserves the port to prevent old packets from interfering with new connections. Since no process is holding the socket open, lsof won’t pick it up—but netstat will show the TIME_WAIT entry in its connection table.
2. Process Crashed Without Releasing the Socket:
   If the process using port 8086 crashed abruptly (e.g., killed with kill -9), the kernel might not immediately clean up the socket resource. The port stays occupied, but there’s no process linked to it anymore—so lsof can’t find it, but netstat still sees the lingering socket in the network stack.

A less likely scenario is that you ran lsof without root privileges, so it couldn’t access system-wide process info—but since you tried multiple lsof commands with no output, the lingering socket/TIME_WAIT state is far more probable.

Quick Fixes for Your Port 8086 Issue #

• If it’s a TIME_WAIT state: Wait a few minutes, and the kernel will automatically release the port. If you need it immediately, you can tweak TCP parameters (like setting net.ipv4.tcp_tw_reuse=1 to allow reusing TIME_WAIT ports) but only do this if you understand the tradeoffs.
• If it’s a lingering socket: Try restarting your network service, or use the ss command (a modern replacement for netstat) with ss -tulpn | grep 8086 to get more detailed info about the stuck port.

内容的提问来源于stack exchange，提问作者Alec.Zhou