Understanding Processes, Ports, and Services

The starting point

A surprising number of backend debugging sessions begin with a sentence like 'the database is running.' That statement can mean several different things. A service manager may report that a unit completed successfully while the actual database cluster is offline. A process can be alive without listening on the port you expect. A port can be open while the application is connected to a different host. Understanding these distinctions turns vague infrastructure problems into concrete checks.

A process is not the same thing as a service

A process is an executing program. A service is a process or group of processes managed according to some operational contract. systemd can start a PostgreSQL cluster, but the top-level PostgreSQL service unit may behave differently from the cluster itself. This is why tools that inspect the actual cluster state can tell you more than one high-level status command.

The same idea applies to application servers. Seeing a Node process does not prove that it is listening on the expected interface and port. The network endpoint is another fact that needs to be checked.

Debug the boundary you actually depend on

If a web application needs PostgreSQL on localhost port 5432, the useful checks are whether the database is running, whether it is listening on that port, whether the configured credentials work, and whether the expected database exists. Each check eliminates a different class of failure.

This layered approach is much faster than repeatedly restarting everything. Restarting can hide the evidence that would have told you what actually went wrong.