Linux socket 激活怎样把监听职责交给 systemd

Linux socket 激活的关键不是让 systemd 替应用处理请求，而是把“监听端点由谁创建、业务进程从哪里拿到它”拆成两个职责。.socket 单元负责创建并持有监听 socket，.service 单元负责启动程序、接收 systemd 传入的文件描述符并处理连接。这样，端口可以先被占住，服务进程按需启动；但应用必须理解它收到的是已经创建好的 socket，而不是一个普通的空闲端口。

官方地址：https://systemd.io/

如果程序能够使用 systemd 的 socket 传递协议，优先从 Accept=no 开始设计：systemd 传入监听 socket，应用自己执行 accept 和连接管理。只有面向 inetd 风格、每个连接启动一个实例的程序，才考虑 Accept=yes。

先看清 .socket 和 .service 各自负责什么

socket 激活把一个网络服务拆成三层：监听地址、激活关系、业务处理。.socket 文件里写 ListenStream=8080 或 Unix socket 路径，systemd 负责创建、绑定并监听；同名的 .service 文件声明要运行的程序。客户端连接到达时，socket 单元可以触发 service，监听端点仍由 systemd 持有。

这带来两个直接变化。第一，服务进程启动时不必再次 bind 同一个端口，否则会得到“地址已被使用”。第二，停止 service 不等于释放监听端点：只要 socket 单元仍然激活，端口仍可能保持可接收状态。排查时要把 demo.socket 和 demo.service 当成两个相关但独立的 unit 看待。

用同名 unit 文件表达监听关系

最小配置可以先使用一个共享服务模型。下面的两个文件只表达配置关系，程序路径需要替换成实际可执行文件。

# demo.socket：只声明 systemd 要持有的 TCP 监听端点
[Unit]
Description=Demo listening socket

[Socket]
# 由 systemd 绑定 TCP 8080，服务进程不再自行 bind
ListenStream=8080
# 默认 Accept=no：把监听 socket 交给同一个 service
Accept=no

[Install]
# 让 socket 在 sockets.target 阶段被启用
WantedBy=sockets.target

# demo.service：只负责启动处理程序并接收已打开的文件描述符
[Unit]
Description=Demo socket-activated service

[Service]
# 程序必须能识别 systemd 传入的 LISTEN_FDS/3 号起始文件描述符
ExecStart=/usr/local/bin/demo-server
# 让程序以前台方式运行，便于 systemd 管理生命周期
Type=simple

[Install]
# socket 激活时由同名 demo.socket 拉起，不必单独监听端口
WantedBy=multi-user.target

通常只需要启用 demo.socket，而不是先启动 demo.service。如果 service 被单独启动，程序仍应能清楚处理“没有收到激活 socket”这一情况；反过来，socket 单元也可以在 service 停止后继续存在。

Accept=no 和 Accept=yes 不是性能开关

Accept=no 时，systemd 将监听 socket 本身传给一个服务单元，应用负责调用 accept、管理并发和决定连接何时关闭。这更适合新写的守护进程，也更容易让应用统一处理连接池、优雅退出和限流。

Accept=yes 时，systemd 针对每个进入的连接启动一个 service 实例，并把已经接受的连接 socket 交给它。它适合兼容 inetd 风格的程序，但会把实例管理、并发上限、启动开销和连接级资源分配交给 unit 模型。它不是把任何普通服务自动变成“每连接一个进程”，程序仍要按照收到的连接 fd 工作。

一个实用判断是：如果应用代码里有明确的 socket 激活适配层，优先用 Accept=no；如果程序原本就是按 inetd 标准输入输出处理单连接，再评估 Accept=yes。不要只因为配置看起来更短就切换模型。

文件描述符、启停关系和采用路径

在 native socket activation 模式下，systemd 会通过环境变量告知服务收到了多少个监听 fd，常见的起始 fd 是 3；程序应使用 systemd 的接口或等价协议检查 LISTEN_PID、LISTEN_FDS，再按约定读取 fd。不要把“fd 3”硬编码成永远只有一个 socket：未来可能增加第二个监听端点，也可能用 FileDescriptorName= 区分多个 fd。

# 查看 socket 单元与它关联的 service，先确认监听职责是否已交给 systemd
systemctl status demo.socket
systemctl list-sockets demo.socket

# 只启动 socket，让端口先由 systemd 持有
sudo systemctl enable --now demo.socket

# 查看被 socket 激活的 service 日志；这里不把日志当成业务成功证明
sudo journalctl -u demo.service -n 50 --no-pager

采用时可以按三步推进：先让程序支持并记录收到的 fd 数量；再部署同名 .socket 与 .service，观察 unit 状态和日志；最后才在有明确连接峰值、冷启动或升级诉求时比较收益。关注指标应包括 socket 激活失败次数、service 启动延迟、连接排队、进程重启后的连接行为，而不是只看 CPU 使用率。

需要谨慎的场景也很明确：程序只会自行 bind 端口、依赖启动参数里的端口而不读取 fd、需要复杂的多进程监听协调，或者连接必须跨进程迁移时，直接套用 socket 激活可能增加排查成本。此时先保留普通 service，再逐步补齐 fd 接收能力。

相关问题

为什么 service 已停止但端口还在？ 因为 socket 单元仍可能处于 active，端口由它持有；需要分别检查并按设计停止 socket。

Accept=no 时程序为什么启动后监听失败？ 常见原因是程序仍在自行 bind 端口，应该改为读取 systemd 传入的监听 fd。

什么时候使用 Accept=yes？ 主要是兼容按单连接工作的 inetd 风格程序；新程序通常从 Accept=no 设计更容易控制生命周期。