Find Linux ports, processes and systemd services

Trace a Linux listening port to its process and systemd unit, distinguish bindings and connections, and avoid killing the wrong service.

When a deployment says "address already in use", find the owner before killing anything. A port belongs to a socket, the socket belongs to a process, and that process may be managed by a service that will immediately restart it. This tutorial follows those relationships with read-only commands.

The examples target Ubuntu with ss from iproute2, ps and systemd. They use port 3000 and a fictional demo-web.service. The commands were documentation-reviewed; no production process was inspected or stopped for this article.

Start with listening sockets

Ubuntu terminal — TCP and UDP listeners

sudo ss -ltnp
sudo ss -ltnp 'sport = :3000'
sudo ss -lunp

For the TCP command, -l selects listeners, -t TCP, -n numeric addresses and -p process information. Elevated privileges may be needed to see other users' process details. UDP does not have TCP's listening/established lifecycle, but the UDP view still shows bound sockets.

Read the local address carefully. 127.0.0.1:3000 is IPv4 loopback; 0.0.0.0:3000 accepts traffic on IPv4 interfaces subject to firewall policy. An IPv6 wildcard can have dual-stack behaviour depending on the socket and system configuration. Do not infer public reachability solely from the port number.

The iproute2 ss manual source documents filters and output options.

Inspect the identified process

Use the PID returned by ss, not the illustrative value below:

Ubuntu terminal — process identity

ps -p 1234 -o pid,ppid,user,lstart,etime,%cpu,%mem,args
sudo readlink -f /proc/1234/exe
sudo readlink -f /proc/1234/cwd
sudo cat /proc/1234/cgroup

The executable path distinguishes a system Node binary from a version-manager installation. The working directory can reveal that an old release is still running. The parent PID and cgroup help identify a supervisor.

Command arguments can contain sensitive values if an application was configured poorly. Review them locally and redact before sharing. Do not dump /proc/1234/environ into a support ticket; environment variables often contain credentials.

PIDs can be reused. If time has passed, rerun ss before taking any action based on an earlier observation.

Ask systemd about the owner

Ubuntu terminal — service mapping

sudo systemctl status 1234 --no-pager
sudo systemctl show demo-web.service   -p MainPID -p ExecStart -p WorkingDirectory -p User -p NRestarts
sudo journalctl -u demo-web.service -n 60 --no-pager

systemctl status can map a PID to its owning unit. It may instead belong to a user service, a container or an interactive shell, so an unexpected result is evidence to follow, not a reason to guess.

A service's main PID might be a wrapper while a child owns the socket. Inspect its process tree and cgroup rather than assuming those PIDs must match. The systemctl reference explains status and property inspection.

If systemd owns the process, a direct kill may trigger its restart policy. When a change is authorized, operate through the correct service after understanding its impact. This diagnostic workflow itself does not require stopping it.

Distinguish listening from connected

Ubuntu terminal — established TCP connections

sudo ss -tnp state established
curl -v --max-time 5 http://127.0.0.1:3000/

A listener proves that a socket is bound, not that the application is healthy. A curl response adds evidence about HTTP handling. Conversely, a client process may show established outbound connections without listening on any port.

A firewall can block traffic even while a wildcard listener exists. Test from the intended network path, and inspect host/provider firewall rules separately. If Nginx is the public entry point, a successful local request still does not prove its upstream configuration is correct.

Make a diagnosis you can act on

Record the port, binding, PID, executable, working directory, service and relevant log error. For an address conflict, decide whether the old service should be retired, the new one should use a different port, or the deployment accidentally started a duplicate.

Avoid broad commands such as killing every Node process. Several unrelated applications can use the same executable. A targeted service restart also needs authorization and a recovery plan.

Use the 502 diagnostic when the symptom appears at Nginx, or single-VPS planning when too many responsibilities have accumulated on one machine. Next.js application development can include this operational documentation.