In a systemd socket unit file, what do the ListenStream= and ListenDatagram= directives each set up, and how does systemd know which service unit to start when traffic arrives on that socket?

## What a socket unit actually declares A systemd socket unit is a description of one or more listening endpoints that systemd will open on the service's behalf. Its `[Socket]` section is mostly a list of `Listen*=` directives, each of which becomes a real socket that systemd binds and listens on. ## ListenStream= `ListenStream=` creates a stream socket — connection-oriented, ordered, reliable. What it binds depends on the value you give: - `ListenStream=8080` — TCP port 8080 on all local addresses. On a dual-stack host this covers IPv4 and IPv6. - `ListenStream=127.0.0.1:8080` — only that address. - `ListenStream=/run/myapp.sock` — an `AF_UNIX` stream socket at that filesystem path. - `ListenStream=@myapp` — a socket in the abstract Unix namespace, which has no filesystem entry. For filesystem sockets the ownership and mode are worth setting explicitly with `SocketUser=`, `SocketGroup=` and `SocketMode=`, because that is the only access control a Unix socket has. ## ListenDatagram= `ListenDatagram=` is the same idea for datagram sockets: `ListenDatagram=5514` gives you UDP port 5514, an absolute path gives you a datagram Unix socket. Datagram sockets have no connections, so there is no accept step — systemd starts the service as soon as a datagram arrives, and the service reads from the inherited descriptor. This also means datagram sockets require the default `Accept=no`; per-connection instantiation makes no sense when there are no connections. ## The other variants The same family covers less common cases: `ListenSequentialPacket=` for `SOCK_SEQPACKET`, `ListenFIFO=` for a named pipe, `ListenSpecial=` for a character device or similar special file, `ListenNetlink=` and `ListenMessageQueue=` for their namesakes. You will rarely write these, but recognising them in a vendor's unit file is useful. ## Several listeners in one unit Nothing stops a unit from declaring more than one endpoint: ```ini [Socket] ListenStream=8080 ListenStream=/run/myapp.sock ``` All of them are passed to the same service, as descriptors 3 and 4 in the order written. Because that order is easy to disturb when someone edits the file, systemd lets you label groups with `FileDescriptorName=`, and the names travel to the service in the `LISTEN_FDNAMES` variable. ## Which service gets started The pairing is by name and nothing else: `myapp.socket` activates `myapp.service`. This is a default, not a hard rule — putting `Service=other.service` in the `[Socket]` section points it somewhere else, which is what you do when several sockets feed the same daemon or when the names cannot match. Once the service is running, `systemctl status myapp.service` reports the relationship on a `TriggeredBy:` line, and `systemctl list-sockets` shows every listening socket unit next to the unit it activates. ## What you enable This is the part that catches people out. To get on-demand behaviour you `systemctl enable --now myapp.socket`, and you leave `myapp.service` disabled. The socket unit carries `WantedBy=sockets.target` in its `[Install]` section, so it comes up very early in boot. If you also enable the service, the service starts at boot on its own and there is nothing left to activate on demand — you have kept the extra unit file and lost the benefit. Conversely, if you enable only the service and forget the socket, the daemon may still work, but it will be binding the port itself with no socket unit involved at all. ## Reading a vendor unit When a distribution ships both `foo.socket` and `foo.service`, the socket unit tells you the whole story of how the service is reachable: which ports and paths, whether it is localhost-only, and whether the daemon is expected to be running all the time or to be spun up on demand. It is usually the first file to read when you are asked "how does anything actually reach this daemon?".