Problem

The orders-api service won't come up on app-host. The deploy ran, but the service log shows gunicorn failing to start and giving up. The box is healthy — plenty of RAM and disk. You're logged in as root.

Find why the new process can't start and name the fix.

Initial setup

• Host: app-host, Alpine. You are root.
• Service: orders-api, served by gunicorn on port 8080, runs as the

orders user. Logs to /var/log/orders-api.log.

Acceptance

You've solved it when:

• You've read the crash log (cat /var/log/orders-api.log) and seen

gunicorn fail with Connection in use: ('0.0.0.0', 8080) and finally Can't connect to ('0.0.0.0', 8080) — i.e. it can't BIND the port.

• You've shown with ss -tlnp that 0.0.0.0:8080 is already in LISTEN,

held by an existing process (gunicorn, pid 731) — and corroborated with ps that pid 731 is an OLD master from the previous deploy that never got stopped.

• You've named the fix: stop the orphaned squatter (kill 731 / stop the

old service unit), then restart orders-api so the new master can bind. And the root cause: the previous deploy's gunicorn master wasn't reaped before the new start, so it kept the listening socket — fix the deploy/restart so the old process is stopped first.