/dev/log socket读写被拒绝是日志全面中断的最底层原因，需依次验证权限、存在性、归属、进程占用及imuxsock与journald协同状态，并统一socket路径避免竞争。
当所有业务日志突然全面中断，且确认应用确实在调用 syslog() 或执行 logger 命令却无任何输出时，/dev/log socket 读写被拒绝 是最典型、最底层的故障原因之一。这不是配置逻辑错误，而是系统级通信通道失效，需按顺序逐层验证。
确认是否真为 /dev/log 连接拒绝
直接复现问题并捕获底层错误：
- 运行
strace -e trace=connect,sendto logger "test"，观察是否出现ECONNREFUSED或EACCES - 执行
logger -p local0.info "probe"后立刻检查：journalctl -n 10 --no-pager | grep -i "refused\|denied\|connect" - 若
ls -l /dev/log显示权限为srw-------（仅 root 可写），普通进程必然被拒；正常应为srw-rw-rw-或至少srw-rw----（属组可写）
检查 /dev/log 文件状态与归属
该 socket 必须存在、可访问、未被抢占：
- 运行
ls -l /dev/log—— 若报 “No such file or directory”，说明 socket 未被创建，imuxsock 未启动或 journald 未接管 - 若存在但权限异常（如属主非 root、组非 adm/syslog、缺少 w 权限），执行修复：
sudo chown root:adm /dev/log && sudo chmod 660 /dev/log - 检查是否被其他进程独占：
sudo lsof -U | grep '/dev/log'—— 正常只应看到systemd-journal或rsyslogd；若出现未知进程，需终止并排查其行为
验证 imuxsock 与 journald 的协同状态
二者必须明确分工，不能冲突或缺位：
- 确认 rsyslog 已加载 imuxsock：
grep -r "module(load=\"imuxsock\"" /etc/rsyslog.{conf,d/*}，缺失则在/etc/rsyslog.conf的 MODULES 段添加module(load="imuxsock")并重启 - 确认 journald 启用了转发：
grep "^ForwardToSyslog" /etc/systemd/journald.conf应返回ForwardToSyslog=yes；若为no或注释掉，需修改并执行sudo systemctl restart systemd-journald - 检查服务依赖关系：
systemctl list-dependencies rsyslog.service --reverse，确保未错误依赖已废弃的syslog.socket单元（尤其在 ARM 设备上易发）
排除 socket 路径竞争（ARM/容器/精简系统高发）
现代系统中 /run/systemd/journal/syslog 和 /dev/log 可能同时存在，引发绑定冲突：
- 运行
ss -xlp | grep -E "(\/dev\/log|\/run\/systemd\/journal\/syslog)"，看哪个进程监听了哪个路径 - 若
rsyslogd尝试绑定/dev/log却失败，而systemd-journald已占/run/systemd/journal/syslog，需统一路径：在 rsyslog 配置中显式指定module(load="imuxsock" SysSock.Name="/run/systemd/journal/syslog") - 重启顺序很关键：先
systemctl stop systemd-journald rsyslog，再systemctl start systemd-journald，最后systemctl start rsyslog
