You put a service behind a systemd socket unit listening on port 8080, and now the service fails at startup with "address already in use" — yet nothing else on the host uses that port. What is going on, and how do you confirm it?

## The contradiction is only apparent "Nothing else uses the port" is usually based on looking for another copy of the application. Under socket activation the process holding the port is `systemd` itself — PID 1 opened it when the socket unit started, and it holds it permanently. Any process that then calls `bind()` on the same address gets `EADDRINUSE`, exactly as it would against any other listener. So the diagnosis is not "a stale process" and not "a lingering socket": it is a daemon that was placed behind a socket unit without implementing the handover. ## Confirming it in thirty seconds ```bash # who holds the listener? ss -tlnp 'sport = :8080' # which unit is it, and what does it activate? systemctl list-sockets --all systemctl status myapp.socket systemctl status myapp.service # look for TriggeredBy: ``` The giveaway is the `users:` field in the `ss` output naming `systemd` at `pid=1`. If instead it names your own daemon, the socket unit is not the culprit and you are looking at an ordinary port conflict — a second copy, a container publishing the port, or a leftover process. That branch is worth stating out loud, because it shows you are actually reading the evidence rather than pattern-matching. ## Establishing whether the binary supports activation The activation contract is opt-in: a program only benefits if it looks for `LISTEN_FDS`, checks `LISTEN_PID`, and uses the descriptors starting at fd 3 instead of creating its own socket. There is no way for systemd to force this on a program that does not implement it. The quickest test needs no unit files: ```bash systemd-socket-activate -l 8080 /usr/local/bin/myapp ``` This opens the socket, sets up the same environment systemd would, and runs the binary. If it serves requests, the program supports activation. If it fails with the same bind error, it does not. Checking the project's documentation for socket activation, or grepping the binary for the variable names, tells you the same thing more crudely. ## The three ways out **Patch the daemon.** The change is small — take the descriptor when one is passed, and fall back to binding when none is. Many daemons already have this and it just needs enabling in their config. **Drop the socket unit.** If the daemon cannot be changed, run it as a plain service that binds the port itself: `systemctl disable --now myapp.socket`, then enable the service. You lose on-demand start and restart continuity, but you get a working service, and a working service beats an elegant broken one. **Change the endpoint.** Occasionally the right answer is that the socket unit and the daemon should listen on different things — for instance systemd holding a Unix socket for local clients while the daemon binds its own TCP port. That is a design change, not a fix, and should be deliberate. ## The mirror-image failure The same misunderstanding produces a second symptom that is worth recognising. Start the service directly with `systemctl start myapp.service` while the socket unit is stopped, and no descriptors are passed at all: `LISTEN_FDS` is unset and the count comes back zero. A daemon that assumes it will always be handed a socket then exits immediately with something like "no sockets passed". The cure is the same fallback path — bind normally when nothing was passed — which is also what makes the binary runnable by hand during development. ## Why this question separates people It is a small puzzle whose answer requires holding two facts at once: that a socket unit opens the port before the service exists, and that the daemon must cooperate to use it. Someone who has only read about socket activation tends to assume it is transparent to the application. Someone who has deployed it knows the first thing you check is whether the daemon supports the protocol at all.