systemd socket 的 Accept=yes 如何启动实例化服务

当一个服务需要“每来一个 TCP 连接就启动一个独立进程”时，systemd socket 的关键配置不是把服务名写得更复杂，而是把监听单元设为 Accept=yes，再提供同名的实例模板 example@.service。systemd 会为每个连接创建一个实例，只把已经接受的连接 socket 交给它；程序本身不再负责同时管理一组连接。

官方地址：https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html

Accept=yes 到底改变了什么

Accept=no 时，systemd 启动一个普通服务，并把监听 socket 交给服务进程，由程序继续 accept() 多个连接。Accept=yes 则由 systemd 负责接受连接；每个连接都触发一个服务实例，实例只拿到这个已接受的连接。

因此，Accept=yes 的配对规则也不同。假设监听单元叫 example.socket，普通模式需要 example.service；实例模式需要 example@.service 模板。这个模板中的 %i 表示实例参数，%I 表示未转义的实例参数，二者适合不同的命名场景。

用一对 unit 文件启动实例化服务

下面的示例监听本机 9090 端口。它只演示 unit 之间的关系，服务程序假定能够读取 systemd 传入的连接 socket。unit 文件中的 # 是合法注释，用来标出容易写错的边界。

# /etc/systemd/system/example.socket
[Unit]
Description=Example per-connection socket

[Socket]
# Accept=yes 让 systemd 为每个进入连接创建 example@.service 实例
ListenStream=9090
Accept=yes
MaxConnections=32
MaxConnectionsPerSource=4

[Install]
WantedBy=sockets.target

# /etc/systemd/system/example@.service
[Unit]
Description=Example connection instance %i
CollectMode=inactive-or-failed

[Service]
Type=simple
# 程序必须支持 socket activation；不要在这里再创建 9090 监听端口
ExecStart=/usr/local/bin/example-worker
# 单连接服务退出后，实例可以按连接释放
StandardInput=socket
StandardOutput=socket
StandardError=journal

这里的 StandardInput=socket 与 StandardOutput=socket 适合传统 inetd 风格程序：连接可以从标准输入输出读写。若程序使用 sd-daemon 的 LISTEN_FDS 协议，则应按程序的接口读取文件描述符，不要同时假设 socket 一定在标准输入上。

为什么写了 @.service 仍然启动失败

最常见的错误是模板名称和 socket 名称不一致，或者程序本身期待监听 socket 而不是单连接 socket。按下面顺序检查，证据比反复执行 restart 更有用。

# 重新加载 unit，并只启动监听单元
sudo systemctl daemon-reload
sudo systemctl enable --now example.socket

# 查看 socket 的 Accept、监听地址和当前连接计数
systemctl show example.socket -p Accept -p Listen -p NConnections -p NAccepted

# 查看模板与已生成实例的加载状态
systemctl status example.socket
systemctl list-units 'example@*.service' --all

# 读取某个实例的真实日志；引号避免 shell 展开通配符
journalctl -u 'example@*.service' -b --no-pager

如果 list-units 里完全没有实例，先确认客户端确实连接到了 9090 端口；如果有实例但日志显示端口绑定失败，通常是服务程序仍在尝试自己监听端口。Accept=yes 的服务不应重复创建监听 socket。

实例参数、连接信息和资源边界怎么用

实例名适合标识这一条连接对应的 unit，但不宜承载完整业务状态。对于 IPv4/IPv6 连接，systemd 可在实例进程环境中提供 REMOTE_ADDR 与 REMOTE_PORT；LISTEN_FDS 则属于程序采用 native socket activation 接口时的传递信息。实际使用哪个变量，要以程序的接收协议为准。

MaxConnections 限制同时运行的连接服务实例，默认值在不同 systemd 版本和发行版文档中应以本机 man page 为准；MaxConnectionsPerSource 可以进一步按来源地址限制。连接稀疏、单连接处理简单时，Accept=yes 能让隔离和权限边界更直观；高并发服务则要把每连接进程的内存、启动成本和调度压力算进去。

一份可以直接复用的排查清单

• 监听单元后缀是 .socket，并且同名模板后缀是 @.service。
• 确认服务程序支持单连接 socket：标准输入输出或 LISTEN_FDS 二选一，按程序文档配置。
• 用 systemctl show 查看 Accept、Listen 和连接计数，不把“socket active”误认为“业务处理成功”。
• 用 journalctl -u 'example@*.service' 对照实例退出原因，优先修正启动命令、权限和 socket 接收方式。
• 为连接型实例设置 CollectMode=inactive-or-failed，再按业务容量设置两个连接上限。

相关问题

Accept=yes 能不能继续使用 example.service？

通常不能。Accept=yes 需要与 socket 同名的服务模板，例如 example@.service，systemd 才能按连接创建实例。

Accept=yes 和 Accept=no 哪个性能更好？

没有脱离场景的固定答案。高并发、长生命周期服务通常更适合让一个服务管理监听 socket；连接稀疏且希望每个连接独立隔离时，按连接实例更容易实现。

%i 和 %I 应该怎么选？

%i 是转义后的实例标识，适合放进 unit 名称相关配置；%I 是未转义形式，适合需要还原原始实例参数的场景。涉及路径或特殊字符时，先查看 systemd.unit 对 specifier 的说明。

为什么服务实例马上变成 failed？

先看实例日志，重点排查程序是否尝试重新监听端口、是否读取了错误的文件描述符，以及 ExecStart 的用户权限和路径是否正确。