Snap services hide from docker ps and systemctl

docker ps doesn't show it. systemctl list-units doesn't show it. The port is listening, the service is answering, and every tool you trust says the machine isn't running it.

You checked snap services, right?

The blind spot

Snap-packaged daemons register with snapd's own service manager, not the systemd system instance you're used to querying. So the standard discovery ladder — systemctl, docker ps, ps aux | grep-ing for something you already know the name of — all report clean while the service sits there serving traffic.

The failure shape, when you hit it: you're port-scanning yourself (or reading a listening-sockets list, ss -tlnp) and find a port you can't attribute. The process names look odd — snap confinement gives them paths like /snap/whatever/1234/bin/thing — and if you grep for the package name instead of the binary name, you miss it anyway.

The commands that actually see it

snap services            # list every snap-managed service and its state
snap list                # what's installed at all
ss -tlnp                 # who actually holds the port (note /snap/ paths)

And the data lives in a place people forget to look and forget to back up:

/root/snap/<pkg>/        # snap data for root-run services
~/snap/<pkg>/            # per-user snap data

The habit

When "nothing is running this port but something is," check snap before you start doubting your own scan. And when you inventory a machine — for backups, migration, or decommissioning — snap list goes on the checklist next to docker ps and systemctl, because a package manager with its own service layer will not appear in either.

The general lesson is older than snap: every service manager you don't think of is a service manager you'll miss. The box runs exactly what it says it runs — across every layer you know how to ask.