In a systemd .socket unit, what changes when you set Accept=yes instead of the default Accept=no, and what must the paired service unit look like in each case?

## Two different activation models The `Accept=` setting picks between two genuinely different designs that happen to share a unit-file syntax. ## Accept=no — one daemon, the listening socket This is the default and the modern model. systemd opens the listening socket, and on the first connection starts the service **once**, handing it the listening descriptor as fd 3. From then on the daemon runs its own `accept()` loop and serves everything itself; systemd is not involved again until the service stops. The unit pairing is the plain one: `myapp.socket` activates `myapp.service`. Everything people usually mean by socket activation — on-demand start, boot parallelisation, restarts that do not refuse connections — comes from this mode. Concurrency is entirely the daemon's business: threads, an event loop, a worker pool, whatever it already uses. ## Accept=yes — one process per connection With `Accept=yes` systemd keeps the listening socket for itself and calls `accept()` on every incoming connection. For each accepted connection it instantiates a **template** unit and passes it just that connection. So the units look like this: ```ini # /etc/systemd/system/echo.socket [Socket] ListenStream=7777 Accept=yes [Install] WantedBy=sockets.target ``` ```ini # /etc/systemd/system/[email protected] [Unit] Description=Echo handler for one connection [Service] ExecStart=/usr/bin/cat StandardInput=socket ``` The `@` in the service name is what makes it a template; systemd starts one instance per connection. `StandardInput=socket` connects the accepted socket to the process's stdin (and, by default, its stdout), which is why a program as simple as `cat` becomes a working echo service. This is deliberately the old inetd contract: a program that reads stdin and writes stdout needs no socket code at all. Note what the service does **not** get here: it never sees the listening socket, so it cannot accept anything else, and when it exits only that one connection ends. ## Why Accept=no is the default answer Cost. Every connection under `Accept=yes` means a unit instantiation, a fork, an exec, and a fresh process's worth of startup — for anything with a runtime to initialise, a config file to parse or a database pool to open, that is orders of magnitude more expensive than an `accept()` call in an existing loop. It also fragments observability: hundreds of short-lived unit instances instead of one unit you can watch. The systemd documentation itself recommends `Accept=no` for all but the most trivial services, and the shipped examples that use `Accept=yes` are things like small diagnostic or legacy line-protocol services. ## The guards that come with Accept=yes Because a process per connection is a denial-of-service invitation, the socket unit has limits for it: - `MaxConnections=` — how many instances may run at once (a modest default; connections beyond it are refused). - `MaxConnectionsPerSource=` — the same cap per originating IP address, which is the one that stops a single client from consuming the whole allowance. Under `Accept=no` these do not apply in the same way, because there is only ever one service instance and the daemon does its own admission control. ## Constraints worth remembering `Accept=yes` requires a connection-oriented socket. A datagram socket has no accept step, so it must use `Accept=no`, and the service reads datagrams from the inherited descriptor directly. And a service unit written for one mode cannot be used in the other unchanged: the `Accept=no` daemon expects to `accept()` on what it is given, while the `Accept=yes` handler expects an already-connected socket. Getting this backwards is a common cause of a service that starts, reads nothing, and exits immediately. ## What to say in an interview Describe both models, name the template-unit requirement for `Accept=yes`, and then say clearly that you would default to `Accept=no` for any real service and reserve `Accept=yes` for trivial or legacy line protocols where a process per connection is genuinely cheap.