A systemd .socket unit declares ListenStream=8080 and there is a matching .service unit. Describe what systemd does at boot, what happens when the first client connects, and how the daemon ends up serving on a socket it never opened itself.

## The idea in one sentence Socket activation moves ownership of the listening socket out of the daemon and into systemd (PID 1). systemd opens the socket early and keeps it open for the whole life of the machine; the daemon behind it is started, stopped and restarted underneath a socket that never closes. ## The socket unit A socket unit is an ordinary unit file with a `[Socket]` section: ```ini # /etc/systemd/system/myapp.socket [Unit] Description=myapp listening socket [Socket] ListenStream=8080 Accept=no [Install] WantedBy=sockets.target ``` `ListenStream=` here means "a stream socket on TCP port 8080". `Accept=no` (the default) means systemd only listens; it does not accept connections itself. The `[Install]` section pulls the socket into `sockets.target`, which is reached very early in boot — this is what you `systemctl enable`, and it is the socket unit you enable, not the service. ## At boot When `myapp.socket` starts, systemd performs the `socket()`, `bind()` and `listen()` calls itself and then does nothing else. `systemctl list-sockets` shows the socket as listening and names the unit it will activate. `ss -tlnp` shows the listener with `users:(("systemd",pid=1,...))` — PID 1 holds it. The service is still inactive; no memory, no threads, no open connections to a database. Because the socket exists from the earliest moments of boot, other units may connect to it before the daemon behind it has ever run. That is the boot-parallelisation payoff: a client unit does not need `After=myapp.service`, because a connection attempt is never refused — it is queued on the listening socket and served whenever the daemon comes up. ## On the first connection The kernel marks the listening socket readable. systemd sees this, starts `myapp.service`, and passes it the descriptor. The service unit is found by name: `myapp.socket` activates `myapp.service` unless the socket unit overrides that with `Service=`. `systemctl status myapp.service` shows this relationship as a `TriggeredBy:` line. ## The handover protocol The contract is deliberately tiny and language-agnostic — it is three environment variables plus inherited descriptors: - `LISTEN_FDS` — how many descriptors were passed. - `LISTEN_PID` — the PID that is supposed to use them. - `LISTEN_FDNAMES` — colon-separated names, from `FileDescriptorName=` in the socket unit, so a daemon given several sockets can tell them apart. The descriptors themselves start at `SD_LISTEN_FDS_START`, which is 3 — immediately after stdin, stdout and stderr. With two `ListenStream=` lines you get fds 3 and 4, in the order the directives appear. `LISTEN_PID` exists because environment variables are inherited across `fork()` and `exec()`. Without the check, any child the daemon spawns would also believe it had been handed sockets. The libsystemd helper does this for you: ```c #include <systemd/sd-daemon.h> int n = sd_listen_fds(1); /* 1 = unset the variables afterwards */ if (n == 1) { int fd = SD_LISTEN_FDS_START; /* == 3 */ /* accept() on fd; never bind()/listen() */ } ``` `sd_listen_fds()` verifies `LISTEN_PID`, returns the count, and with a non-zero argument clears the variables so children cannot misread them. `sd_listen_fds_with_names()` returns the names as well. Nothing forces you to link libsystemd — the variables are documented and trivially readable from any language. ## What the daemon has to change Exactly one thing: when descriptors are passed, do not create your own socket. A well-behaved daemon checks the count, uses the inherited fds when there are any, and falls back to binding normally when there are none — which is what lets the same binary run standalone during development and socket-activated in production. A daemon that ignores the passed descriptors and binds the port anyway fails immediately with `EADDRINUSE`, because systemd is already bound to it. ## Why it is worth the trouble Two things. First, on-demand start: a rarely used service costs nothing until someone connects. Second, restarts that do not refuse connections — the listening socket lives in PID 1, so stopping and starting the service leaves it open and the kernel queues arrivals in the meantime. To try a binary without writing units, `systemd-socket-activate -l 8080 ./myapp` sets up the socket and the environment exactly as systemd would, which is the quickest way to find out whether a program supports the protocol at all.