How to know which process occupies a port in Linux with ss and lsof
Published on 2026-10-26 by frfrand
Discover occupied ports and services listening on Ubuntu
Nginx attempts to send requests to port 8000 and finds nothing. Did the API die or is another process using that port? ss and lsof allow you to see who is listening and what files or sockets they have open.
I'll show you where the problem is, how to verify it without guessing, and what I would do in an application that actually has users. You don't need to memorize an entire manual to fix a specific failure.
What ss and lsof mean in practice
ss queries system sockets and displays listening addresses, while lsof lists file descriptors associated with processes. To see the PID or executable of other users, sudo is usually required. A process listening on localhost does not mean it is accessible from the Internet.
A clarification before touching the server: if the project is already in production, save the state you found and check which user and machine you will execute the commands on. Working as root without need and changing several things at once makes it difficult to find the cause of an error.
Useful commands to get started
sudo ss -ltnp
sudo ss -ltnp '( sport = :8000 )'
sudo lsof -nP -iTCP:8000 -sTCP:LISTEN
curl -i http://127.0.0.1:8000/health
sudo systemctl status miappPaths, unit names, and domains are examples. Adapt them to your service. If a command requires administrator permissions, check what changes and why. Diagnostic queries should come before modifications.
Step by step, with checks
- Check if a TCP socket is listening on the expected port.
- Verify if it listens on
127.0.0.1, on a specific IP, or on all interfaces. - Identify PID and service; do not kill processes just for recognizing their number.
- Make a local request and another through Nginx to isolate the segment.
- If the port is occupied, correct the service configuration and check logs.
After each step, verify an observable result: a status, a file, an HTTP response, or a log entry. If you find an unexpected message, save it for investigation instead of hiding it with repeated restarts.
Real example: an application that needs maintenance
You have two FastAPI projects on the same VPS. Both try to listen on 8000, so the second one fails. With ss you find the process and assign different internal ports with Nginx by domain.
At the end, test the full path: enter through the domain, call the API, write a test data and verify that the information is still there after a controlled restart. A server that "starts" is not always an application that works.
Mistakes worth avoiding
Do not use kill -9 as an initial solution; it can interrupt transactions or tasks. First identify the service supervisor and its configuration.
It is also important that credentials do not end up in terminal history, logs, shared files, or screenshots. For users and services, use minimal permissions and document who can revoke access.
How ArduMaker fits into this scenario
An ArduMaker VPS can host several applications behind Nginx. Documenting the internal port, domain, and systemd service avoids conflicts between projects.
ArduMaker can help you manage VPSs, deploy repositories, and work with services, databases, and domains from the same platform. It does not replace what we just explained about Linux: precisely for that reason, it is worth understanding diagnostics and having a way to repeat them.
When it is worth automating it
If the task is repeated, document the manual procedure and its checks first. Then consider a script or a scheduled task with visible errors, logs, and limited permissions. Do not automate a command that you still do not know how to recover when it goes wrong.
Frequently asked questions
Can I try it without affecting customers? In many cases, yes: a staging VPS or a separate test service allows you to validate the configuration before changing production.
How do I know it worked? Check logs and a functional operation, not just that the command ended with a zero code.
When do I need more resources? When metrics indicate CPU, RAM, disk, or connection saturation. A configuration failure is rarely fixed by hiring more memory.
References
In one sentence: first understand the error, then change one concrete thing and check its effect. That discipline saves you many hours of support.