About this article
This article is created using an automated generation workflow leveraging generative AI. It is organized as a diagnostic procedure to link listening ports and processes by checking the Linux ss(8) manual and TCP RFC 9293.Verification Status: 🧪 Primary source verified, 0 results/invalid input/LISTEN logic verified on Debian 13, Ubuntu physical machine not verified
Checking “Who is listening on this port?” in Ubuntu — Linking sockets and processes with ss
If you want to investigate “Who is using port 5000?” on Ubuntu, you can filter TCP LISTEN sockets using ss and check the process information as needed.
ss -lntpH "sport = :5000"
With this single line, you can narrow it down to TCP, listening, numeric display, process display, and no headers.
Breaking down the options
| Option | Meaning |
|---|---|
-l | Display listening sockets |
-n | Display addresses and ports numerically without converting to service names |
-t | Display TCP sockets |
-p | Display process information using the socket |
-H | Do not display the header line |
-H is used not only to keep the output short, but also in this script to make it easier to determine “empty output if there are 0 matching sockets.”
Viewing from Process → Socket → IP:Port
flowchart LR
A[process / PID] --> B[TCP socket]
B --> C[LISTEN state]
C --> D[local IP : port]
D --> E[接続を待つ]
Rather than just looking at the port number, it is easier to understand if you connect and view which process binds to which local address and whether that socket is listening.
127.0.0.1 and 0.0.0.0 have different meanings
For example, suppose port 5000 appears as follows:
127.0.0.1:5000 0.0.0.0:5000 [::]:5000
127.0.0.1:5000is listening on the IPv4 loopback. This is basically configured for use from within the same PC.0.0.0.0:5000is the IPv4 unspecified address, used for listening on multiple local IPv4 addresses.[::]:5000is the IPv6 unspecified address. Whether it also accepts IPv4 connections depends on the OS and socket settings, so do not assume based solely on the display.
Merely saying “port 5000 is open” does not clarify whether it is reachable from the outside. Check the bind address, firewall, routing, etc., separately.
Process information may not always be visible
Even with -p specified, details of other processes may not be fully displayed depending on the execution user’s privileges.
In that case, first check if the socket itself exists, and if process information is needed, re-check with sudo after considering the necessity of privileges.
sudo ss -lntpH "sport = :5000"
Rather than assuming sudo every time, it is safer to distinguish what information is missing due to insufficient privileges.
When nothing is output
If this filter outputs nothing, you can determine that “no socket listening on TCP port 5000 locally was found with this check.”
However, the following are different issues:
Using UDP port 5000 → Not displayed by
-tLocated within a different network namespace
The service crashed right after startup
Causes of connection rejection or communication failure exist in the firewall, etc.
You cannot definitively conclude that “not showing up in ss = the application configuration is definitely wrong.”
Local logic verification
Verified three cases on 2026-09-07 using Debian GNU/Linux 13, Bash 5.2.37, and iproute2 6.15.0: unused port, invalid input, and temporary localhost TCP LISTEN. Verification on an actual Ubuntu machine has not been performed.
