Socket activation in systemd, and why your service "isn't running"

A fairly common moment of panic: you run systemctl status ssh on a fresh box, see inactive (dead), and conclude SSH is down. Except you're connected to the box over SSH right now. So what's actually inactive?

Two units, one service

On systems that ship socket activation for SSH (several Ubuntu images do this by default), there are two separate units: ssh.socket and ssh.service. The socket unit is what actually listens on port 22. It doesn't run the SSH daemon itself — it just holds the listening socket open and waits.

When a connection comes in, systemd hands that connection to ssh.service, starting it on demand if it isn't already running. Between connections, the service unit can sit inactive indefinitely. That's by design, not a failure state — the daemon has a right to not be running when nobody's knocking.

systemctl status ssh.socket   # this is what's actually listening
systemctl status ssh.service  # this starts on demand, may show inactive

Where this actually causes problems

Socket activation is transparent right up until you need to change something socket-level — a listening port, for instance. Editing /etc/ssh/sshd_config and restarting ssh.service changes nothing about what port is being listened on, because the socket unit owns that, and it has its own config in /etc/systemd/system/ssh.socket.d/ or the unit file itself.

If you've edited sshd_config for a custom port and restarts aren't picking it up, that's usually why. The fix, if you want full control over the listening behavior and don't need socket activation's lazy-start benefit, is to disable the socket unit and enable the plain service instead:

systemctl disable --now ssh.socket
systemctl enable --now ssh.service

This gives you a normal, always-running daemon that starts at boot and listens immediately — no activation indirection, and config changes behave exactly the way every tutorial assumes they will.

Checking what's actually bound

When in doubt about which unit owns a port, skip systemd entirely and ask the kernel:

ss -tlnp | grep ':22\b'

The process name in that output tells you the truth regardless of which unit systemd thinks is responsible. It's the fastest way to cut through activation confusion — if something is listening, this will show it, full stop.

Takeaway

"Inactive" doesn't mean "not working." It can mean "sleeping until you knock." Before assuming a service is down, check whether a socket unit might be fronting it — a quick systemctl list-units --type=socket will show you everything on the box set up this way.