systemd ListenStream 与 ListenDatagram 怎么选

ListenStream= 与 ListenDatagram= 应按服务期待的 socket 类型选择：IP 地址上的 TCP 用 ListenStream，UDP 用 ListenDatagram；Unix 本地 socket 也分别有流式和数据报类型。端口相同、路径相似都不代表可以互换。选择之前，还要确认服务能接收 systemd 传入的 socket，而不是只会自己创建并绑定端口。

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

问题：服务需要字节流，还是一条条数据报

面对一个监听配置，先问程序使用什么协议和读写模型。TCP 服务通常在监听 socket 上接受连接，再从连接中读取连续字节；UDP 服务则接收一条条数据报。把 ListenStream 改成 ListenDatagram，不会替程序完成协议转换，也不会让原本的 TCP 客户端自动变成 UDP 客户端。

本地文件路径同样不能决定类型：Unix 字节流与 Unix 数据报都可以使用路径形式地址。命名为 control.sock 的文件既可能对应流式协议，也可能对应数据报协议，需要与程序约定一致。本文按“小配方、关键配置、变体与完整片段”组织，便于按实际服务选择。

最小配方：先用明确的回环地址

假定程序支持原生 socket activation，并且需要接管 TCP 监听 socket，可准备如下 example-daemon.socket。这是配置骨架，不包含可直接运行的服务程序。

# example-daemon.socket：本例按 TCP 字节流创建监听端点。
[Unit]
Description=Example stream socket

[Socket]
ListenStream=127.0.0.1:9123
Accept=no

[Install]
WantedBy=sockets.target

这里显式绑定 127.0.0.1，表示 IPv4 本机回环。只写端口数字可能涉及 IPv6 与双栈行为，不能把它直接理解成只对本机监听。实际监听范围应按服务需要单独确定。

如果服务使用 UDP，可把同一个文件的 Socket 段替换成下面内容。注意是二选一的变体，并非追加一个同端口的流式监听后就完成了兼容。

# UDP 变体：替换上面的 [Socket] 段，不要同时保留 ListenStream。
[Socket]
ListenDatagram=127.0.0.1:9123
Accept=no

关键配置：类型、地址和接管模式分别决定什么

Accept=no 时，systemd 把监听 socket 交给一个服务管理。对于流式 socket，Accept=yes 是另一种模型：每条连接激活一个模板服务实例，传入的是已连接 socket。它要求对应的模板服务与程序处理模型配套，不适合只改一行就套用。

数据报 socket 没有相同的“每条连接”分派模型。官方文档说明 Accept 对数据报被忽略，由一个服务处理流量。不要试图用 Accept=yes 把 UDP 每个数据报变成一个独立服务实例。

变体：Unix socket 仍然需要匹配流式或数据报

若客户端与服务在同一台机器上，且程序使用 Unix 字节流，可以替换为路径式监听。下面的 SocketMode 约束文件节点访问模式，具体运行用户与目录安排还需结合服务部署设计。

# Unix 字节流变体：替换 [Socket] 段中的地址与类型。
[Socket]
ListenStream=/run/example-daemon/control.sock
SocketMode=0600
Accept=no

若程序实际使用 Unix 数据报，应改用 ListenDatagram 并保持双方类型一致。路径地址开头的斜线表示文件系统 Unix socket；抽象命名空间还有不同写法与生命周期，不要把文件节点权限规则直接套过去。

兼容坑：socket 已经存在，不等于服务会使用

systemd 可以创建监听端点并在有流量时激活服务，但程序必须接收传入描述符。原生接口通常通过 sd_listen_fds 读取管理器提供的描述符集合；程序应核对它们是否为自己支持的流式或数据报 socket，再使用对应的处理方式。

如果服务启动后仍对同一地址执行普通 bind，可能报地址占用；如果它忽略描述符，也可能一直不消费已到达的数据。仅修改 ExecStart 或增加一个 socket unit 不能替不支持激活的程序实现接管。部署前应依据该程序的官方接口确认它采用原生传递还是 inetd 风格。

不要把描述符“从 3 开始”理解为永远只有一个 socket 且顺序固定。一个服务可能接收多个监听端点，多 socket unit 还会影响顺序约定。应检查类型及必要的识别信息，而不是在业务代码中固定把第一个当 TCP、第二个当 UDP。

完整片段：配套 service 只负责启动兼容程序

前面的 socket 文件名为 example-daemon.socket，Accept=no 下对应的普通服务文件可命名为 example-daemon.service：

# example-daemon.service：程序路径是占位，须替换为支持描述符接管的服务。
[Unit]
Description=Example socket-activated daemon

[Service]
Type=simple
ExecStart=/usr/local/libexec/example-daemon

/usr/local/libexec/example-daemon 是占位程序路径，不代表系统内置命令。必须替换为实际安装、且支持监听描述符接管的程序。不要直接使用这个不存在的路径启动服务，也不要自行添加未经该程序文档确认的“接管开关”。

这份骨架不需要把 service 自己启用成另一个独立的监听启动入口。由 socket 负责入口可以避免配置思路混乱；程序启动后的连接管理、数据报解析、错误处理仍属于服务实现。服务退出时也不应随意 unlink systemd 管理的 Unix socket 路径，或对 Accept=no 传入的共享监听 socket 调用 shutdown，影响管理器保留的监听端点。

常见问题

同一个端口数字能同时配置 TCP 和 UDP 吗

这是不同协议的端点，可以有相同端口数字，但程序必须确实支持两种协议并接管多个描述符。只为了“保险”同时配置两种监听，通常会增加歧义。

ListenStream 是否保留每次发送的消息边界

流式协议提供字节流，应用需要自己的消息分帧规则，例如长度前缀或明确分隔。不要把一次读取等同于客户端的一次发送。

选 ListenDatagram 就能避免消息丢失吗

不能。配置类型只说明数据报语义，不代替可靠传输、缓冲管理与业务确认。需要怎样的可靠性，应由具体协议与服务设计决定。

参考资料

• systemd.socket：监听类型、地址与 Accept
• sd_listen_fds：服务接管描述符
• systemd 项目文档入口