ss -p: show which process owns a socket (and why it is empty without root)
- tool
- ss / netstat
- command
- ss
- flag
- -p, --processes
- default
- off (no process information is printed)
ss -p adds the process that uses each socket to the output, in a users:((...)) field with the program name, its PID and the file descriptor number. Combined with other options it answers "which program is listening on port 8080?": sudo ss -ltnp 'sport = :8080'. ss discovers owners by scanning /proc/*/fd, so without root privileges it can only show your own processes; other sockets are listed without the field rather than with an error.
Typical commands
sudo ss -ltnp # listening TCP sockets with their processes
sudo ss -lunp # the same for UDP
sudo ss -tnp state established # established TCP connections and owners
sudo ss -ltnp 'sport = :443' # who listens on port 443
ss -tnp # your own processes only (no sudo)The letters combine: -l listening, -t TCP, -u UDP, -n numeric (no service-name lookup), -p processes. The well-known ss -tulpn is the netstat-style one-liner for all listening TCP and UDP ports; see list listening ports.
Related options
| Option | Adds |
|---|---|
| -p, --processes | Process name, PID and fd in users:((...)) |
| -T, --threads | Thread IDs; implies -p |
| -e, --extended | uid, inode number and socket cookie |
| -o, --options | TCP timer information (retransmit, keepalive, timewait) |
| -i, --info | Internal TCP information such as rtt, cwnd and retransmits |
| -m, --memory | Socket memory usage (skmem) |
| -H, --no-header | Drops the header line, for scripts |
Using the result
To get only the PID of the process on a port, filter the pid= part: sudo ss -ltnpH 'sport = :8080' | grep -o 'pid=[0-9]*' | cut -d= -f2. Several entries in users:((...),(...)) mean that several processes share the socket, typically a master process and its forked workers (nginx, Apache, Gunicorn), all holding the same listening descriptor.
Pitfalls
- Containers and namespaces. ss shows the sockets of the current network namespace. A port published by a container may belong to
docker-proxyor be handled by NAT rules without any listening process on the host; run ss inside the container's namespace (nsenter -t PID -n ss -ltnp) to see the real owner. - Speed on large hosts.
-pis slower than plain ss because it scans every process's file descriptors; on hosts with many thousands of sockets filter first (by state or port) to keep it fast. - Missing ss. Minimal images may lack iproute2; see ss: command not found.
More filters and output fields are collected in the ss cheat sheet, and the differences from netstat in ss vs netstat.
FAQ
Why does ss -p show no process for some sockets?
ss finds the owner by reading /proc/PID/fd of every process. As a normal user you can only read your own processes, so sockets of root or other users have no users:(...) field. Run the command with sudo to see all owners.
What is the difference between -p and -T?
-p lists the processes that hold the socket; -T (--threads) lists threads and implies -p. Threads matter for programs where one worker thread owns the descriptor.
Is ss -tulpn the same as netstat -tulpn?
It answers the same question, listening TCP and UDP sockets with numeric ports and their processes, and uses the same letters. ss reads the kernel's netlink interface and is faster on busy hosts; netstat is deprecated on most distributions.