AF_UNIX套接字connect返回errno 111，glibc syslog为何调用connect前不执行bind？

问题背景 #

你给出的是glibc中syslog模块的openlog_internal实现源码，核心疑问有两点：修改sun_path后调用connect返回errno 111（即ECONNREFUSED，连接被拒绝），但主动添加bind调用后连接成功，为什么原生glibc实现没有在connect前执行bind操作。

问题解答 #

1. 首先明确AF_UNIX SOCK_DGRAM套接字的默认行为
   对于未显式执行bind的AF_UNIX域数据报套接字，Linux内核会自动为其分配一个抽象命名空间下的唯一临时地址，不需要用户手动管理地址，只要目标地址合法、有服务端监听，connect操作默认可以正常完成。

2. 为什么原生glibc实现不需要显式bind
   原生实现的目标地址是标准路径/dev/log，这个路径是所有syslog服务端（rsyslog、syslog-ng等）的默认监听地址：

• 该路径的套接字默认权限对所有用户进程开放可写权限，没有源地址校验限制
• 系统默认的安全策略（SELinux、AppArmor等）都允许未绑定的AF_UNIX套接字访问/dev/log
• syslog客户端绝大多数场景下只需要向服务端发送日志，不需要接收服务端回包，不需要固定的源地址
  因此glibc选择省略bind调用，减少不必要的系统调用开销，也避免了手动bind可能带来的路径冲突、权限不足、资源释放等额外问题。

3. 为什么修改sun_path后会出现ECONNREFUSED，加bind就成功
   errno 111本质是目标地址没有服务端监听，或者连接被服务端/安全模块拒绝，加bind后成功的常见原因有两个：

• 你修改后的目标地址对应的syslog服务端做了源地址校验，只允许绑定了特定路径/抽象地址的客户端连接，显式bind到符合要求的地址后就通过了校验
• 系统的安全策略限制了未绑定的AF_UNIX套接字访问你自定义的路径/抽象地址，显式bind到安全策略允许的地址后就解除了访问限制
  可优先确认自定义路径的套接字确实存在、权限正确、服务端处于正常监听状态，再排查服务端配置和系统安全策略的限制。

内容的提问来源于stack exchange，提问作者scq