{"id":196,"date":"2026-07-29T09:00:00","date_gmt":"2026-07-29T09:00:00","guid":{"rendered":"https:\/\/backendside.com\/blog\/?p=196"},"modified":"2026-07-29T18:07:47","modified_gmt":"2026-07-29T18:07:47","slug":"find-process-using-port-linux","status":"publish","type":"post","link":"https:\/\/backendside.com\/blog\/2026\/07\/29\/find-process-using-port-linux\/","title":{"rendered":"Which Process Is Using That Port? Mapping a Listening Port to a PID on Linux"},"content":{"rendered":"

You restart a service and it refuses to come up: bind: Address already in use<\/em>. Or you run a security scan and find port 9001 open on a box where nothing is supposed to be listening on 9001. Both problems reduce to the same question—which process owns this listening socket?<\/strong> Linux will tell you, and it takes one command. Here is that command, three alternatives for when it is not installed, and what to do in the awkward cases where a port seems to belong to nobody at all.<\/p>\n

The short answer<\/h2>\n

On any reasonably modern distribution, this is the whole trick:<\/p>\n

sudo ss -ltnp<\/code><\/pre>\n
That lists every TCP socket in the LISTEN state, without resolving names, with the owning process attached. Output looks like this:<\/p>\n
State   Recv-Q  Send-Q   Local Address:Port   Peer Address:Port  Process\nLISTEN  0       128            0.0.0.0:22          0.0.0.0:*      users:((\"sshd\",pid=811,fd=3))\nLISTEN  0       511            0.0.0.0:80          0.0.0.0:*      users:((\"nginx\",pid=1187,fd=6),(\"nginx\",pid=1186,fd=6))\nLISTEN  0       4096         127.0.0.1:3306        0.0.0.0:*      users:((\"mariadbd\",pid=942,fd=25))\nLISTEN  0       4096                  *:8080               *:*    users:((\"backendsidemon\",pid=1502,fd=9))<\/code><\/pre>\n
The last column is the answer. users:((\"nginx\",pid=1187,fd=6))<\/code> means: the process named nginx<\/code>, PID 1187, is holding this socket on file descriptor 6. Port 80 shows two entries because a master process and a worker both hold the listening descriptor—that is normal for pre-forking servers.<\/p>\n
To look at one port instead of all of them, use a filter rather than piping to grep<\/code>—it avoids matching the port number in some other column:<\/p>\n
sudo ss -ltnp 'sport = :8080'<\/code><\/pre>\n
The flags, decoded<\/h3>\n\n\n\n\n\n\n\n\n\n\n
Flag<\/th>\nWhat it does<\/th>\nWhy you want it<\/th>\n<\/tr>\n<\/thead>\n
-t<\/code> \/ -u<\/code><\/td>\nTCP \/ UDP sockets<\/td>\nFilters out the pile of Unix domain sockets<\/td>\n<\/tr>\n
-l<\/code><\/td>\nListening sockets only<\/td>\nA server binding a port is what you are hunting<\/td>\n<\/tr>\n
-n<\/code><\/td>\nNumeric — no name resolution<\/td>\nShows :8080<\/code>, not :http-alt<\/code>; also much faster<\/td>\n<\/tr>\n
-p<\/code><\/td>\nShow the owning process<\/td>\nThe entire point — needs root for other users’ processes<\/td>\n<\/tr>\n
-a<\/code><\/td>\nAll sockets, not just listening<\/td>\nUse when chasing an established connection instead<\/td>\n<\/tr>\n
-e<\/code><\/td>\nExtended info, including the socket inode<\/td>\nThe escape hatch when -p<\/code> gives you nothing<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Why you almost always need sudo<\/h2>\n
Run ss -ltnp<\/code> without root and the Process column will be blank for everything you do not own. The kernel only lets you map a socket back to a PID if the process is yours or you have CAP_NET_ADMIN<\/code>. This trips people up constantly: the port is clearly listed as LISTEN, the process field is empty, and it looks like a ghost. It is not a ghost—it is a permissions problem. Add sudo<\/code> and try again before you go any further.<\/p>\n
\n
🔧 BackendSide Tool<\/div>\n
BackendSideMon — See Every Listener and Its Process in a Browser<\/h4>\n
Running ss -ltnp<\/code> is fine when you have one server and an SSH session already open. BackendSideMon<\/strong> gives you the same answer as a live web dashboard: active listeners and connections with local and remote IPs, ports and states, alongside the running processes and their full executable paths. It installs as a systemd service on RHEL-based and Debian\/Ubuntu-based distributions and serves the dashboard on port 8080.<\/p>\n
  Explore BackendSideMon →<\/a>\n<\/div>\n
When ss<\/code> is not there: three fallbacks<\/h2>\n
1. lsof<\/code> — the most readable output<\/h3>\n
lsof<\/code> treats sockets as what they are on Linux: open files. Ask it which files match an internet address:<\/p>\n
sudo lsof -i :8080 -sTCP:LISTEN -P -n\n\nCOMMAND          PID  USER   FD   TYPE DEVICE SIZE\/OFF NODE NAME\nbackendsidemon  1502  root    9u  IPv6  28841      0t0  TCP *:8080 (LISTEN)<\/code><\/pre>\n
-P<\/code> and -n<\/code> keep ports and addresses numeric, and -sTCP:LISTEN<\/code> drops established connections so you only see the binding process. For scripting, -t<\/code> prints bare PIDs and nothing else:<\/p>\n
sudo lsof -t -i :8080 -sTCP:LISTEN\n1502<\/code><\/pre>\n
2. fuser<\/code> — fastest when you only want the PID<\/h3>\n
sudo fuser 8080\/tcp\n8080\/tcp:             1502\n\nsudo fuser -v 8080\/tcp\n                     USER        PID ACCESS COMMAND\n8080\/tcp:            root       1502 F....  backendsidemon<\/code><\/pre>\n
fuser<\/code> also has -k<\/code>, which kills whatever it finds. It is genuinely useful and genuinely dangerous—sudo fuser -k 8080\/tcp<\/code> will happily terminate a production database if that is what answered. Always run it without -k<\/code> first and read the output.<\/p>\n
3. netstat<\/code> — the one in every old runbook<\/h3>\n
sudo netstat -tulpn | grep ':8080'\ntcp6  0  0 :::8080   :::*   LISTEN   1502\/backendsidemon<\/code><\/pre>\n
netstat<\/code> comes from the deprecated net-tools<\/code> package and is not installed by default on most current distributions. It reads \/proc\/net\/tcp<\/code> by walking every process’s file descriptors, which is noticeably slow on a busy machine. Learn ss<\/code>; keep netstat<\/code> for the servers you inherited.<\/p>\n
From PID to the whole story<\/h2>\n
A PID and a process name are rarely the end of the investigation—”python3″ or “java” tells you nothing. Once you have the number, \/proc<\/code> gives you everything else:<\/p>\n
# Full command line, owner, parent, and how long it has been up\nps -p 1502 -o pid,ppid,user,etime,cmd\n\n# The actual binary on disk (survives a renamed process)\nsudo ls -l \/proc\/1502\/exe\n\n# Its working directory - often reveals which deployment it belongs to\nsudo ls -l \/proc\/1502\/cwd\n\n# The raw argv, NUL-separated\nsudo tr '\u0000' ' ' < \/proc\/1502\/cmdline; echo\n\n# Which systemd unit or container owns it\ncat \/proc\/1502\/cgroup\nsystemctl status 1502<\/code><\/pre>\n
That last one is the most useful and the least known: systemctl status <pid><\/code> resolves a PID to its owning unit, so you find out that port 8080 belongs to backendsidemon.service<\/code> and can stop it properly instead of killing it.<\/p>\n
The manual method: socket inodes<\/h3>\n
If -p<\/code> gives you nothing and you have already ruled out permissions, you can do the mapping by hand. Every socket has an inode number, and every process holding it has a symlink to socket:[inode]<\/code> in its file-descriptor directory:<\/p>\n
$ sudo ss -ltne 'sport = :8080'\nLISTEN 0 4096 *:8080 *:*  ino:28841 sk:3 cgroup:\/system.slice\/backendsidemon.service\n\n$ sudo find \/proc\/[0-9]*\/fd -lname 'socket:[28841]' 2>\/dev\/null\n\/proc\/1502\/fd\/9<\/code><\/pre>\n
The path contains the PID. This is exactly what ss<\/code>, lsof<\/code> and netstat<\/code> do internally—it is worth seeing once, because it explains why these tools need root and why they get slow on machines with tens of thousands of open descriptors.<\/p>\n
The awkward cases<\/h2>\n
The port is listed but the process column is empty<\/h3>\n
In order of likelihood: you forgot sudo<\/code>; the socket belongs to a process in a different network namespace (a container); or the listener is kernel-side—NFS and some tunnelling code bind ports with no userspace process behind them at all.<\/p>\n
Nothing is listening, but the bind still fails<\/h3>\n
Check for lingering sockets in TIME_WAIT<\/code> from the previous instance:<\/p>\n
sudo ss -tan state time-wait '( sport = :8080 or dport = :8080 )'<\/code><\/pre>\n
Also worth checking: the port may fall inside the ephemeral range and have been grabbed by an outbound connection. Compare against sysctl net.ipv4.ip_local_port_range<\/code>—if your service wants a port inside that window, add it to net.ipv4.ip_local_reserved_ports<\/code> so the kernel stops handing it out to clients.<\/p>\n
You see an IPv6 line but no IPv4 line<\/h3>\n
A single socket bound to [::]<\/code> serves both families on a dual-stack system, so one tcp6<\/code> row can absolutely be the thing answering your IPv4 requests. The reverse also matters: 127.0.0.1:3306<\/code> means loopback only, while 0.0.0.0:3306<\/code> means every interface on the box. When you are auditing exposure, the bind address matters more than the port number.<\/p>\n
The listener is inside a container<\/h3>\n
Containers have their own network namespace, so a process listening inside one may be invisible to ss<\/code> on the host—or show up as a proxy process rather than the real service. List the namespaces, then look inside the one you care about:<\/p>\n
lsns -t net\nsudo nsenter -t 4711 -n ss -ltnp   # 4711 = a PID inside the target namespace<\/code><\/pre>\n
The owner is systemd itself<\/h3>\n
With socket activation, systemd holds the listening socket and only starts the real service when the first connection arrives. Until then the port genuinely belongs to PID 1. systemctl list-sockets<\/code> shows every such socket and the unit it will hand off to.<\/p>\n
A repeatable troubleshooting order<\/h2>\n
    \n
  1. sudo ss -ltnp 'sport = :PORT'<\/code> — the answer, 90% of the time.<\/li>\n
  2. No process shown? Confirm you used sudo<\/code>, then check lsns -t net<\/code> for containers.<\/li>\n
  3. Got a PID? Run systemctl status PID<\/code> to find the owning unit, and ls -l \/proc\/PID\/exe<\/code> to see the real binary.<\/li>\n
  4. Stop it the right way — systemctl stop <unit><\/code> beats kill<\/code>, which beats fuser -k<\/code>.<\/li>\n
  5. Nothing listening but the bind fails? Look for TIME_WAIT<\/code> and check the ephemeral port range.<\/li>\n<\/ol>\n
    \n
    🔧 BackendSide Tool<\/div>\n
    Stop SSH-ing Into Servers Just to Run ss<\/code><\/h4>\n
    Port audits get tedious once you have more than a couple of machines. BackendSideMon<\/strong> runs as a lightweight monitoring service on Windows Server and Linux and puts the whole picture in one dashboard — TCP\/UDP\/ICMP packet statistics, running processes with their executable paths, every active listener and connection, and failed SSH login tracking. There is an optional Android client too, so you can check a fleet of servers from your phone.<\/p>\n
      Explore BackendSideMon →<\/a>\n<\/div>\n
    Key takeaways<\/h2>\n
      \n
    • sudo ss -ltnp<\/code> is the command to memorise.<\/strong> Listening TCP sockets, numeric, with the owning process—everything else is a fallback.<\/li>\n
    • Without root, the process column is empty.<\/strong> That is a permissions artefact, not a mystery process.<\/li>\n
    • lsof -i :PORT -sTCP:LISTEN -P -n<\/code> is the friendliest alternative<\/strong>, fuser<\/code> the quickest, and netstat -tulpn<\/code> the one your old runbooks assume.<\/li>\n
    • A PID is a starting point, not an answer.<\/strong> \/proc\/PID\/exe<\/code>, \/proc\/PID\/cwd<\/code> and systemctl status PID<\/code> turn “java” into a named service you can actually stop.<\/li>\n
    • Read the bind address, not just the port.<\/strong> 127.0.0.1<\/code> and 0.0.0.0<\/code> are completely different exposure stories.<\/li>\n
    • Containers, socket activation and TIME_WAIT<\/code><\/strong> explain nearly every case where the port appears to belong to nobody.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
      A service will not start because “Address already in use”. A port is open that nobody can account for. Both questions come down to the same thing: which process owns this listening socket? Here is how to answer it with ss, lsof, fuser and \/proc \u2014 plus what to do when the port appears to belong to nobody at all.<\/p>\n","protected":false},"author":1,"featured_media":198,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,4,8],"tags":[],"class_list":["post-196","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","category-networking","category-tutorials"],"_links":{"self":[{"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/posts\/196","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/comments?post=196"}],"version-history":[{"count":1,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/posts\/196\/revisions"}],"predecessor-version":[{"id":199,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/posts\/196\/revisions\/199"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/media\/198"}],"wp:attachment":[{"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/media?parent=196"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/categories?post=196"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/tags?post=196"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}