把老服务迁到新的 systemd unit，加了 PrivateTmp=true 做加固，启动时报 connect /tmp/app.sock no such file，可文件明明就在 /tmp 下。
一开始怀疑是「unit 里还配了 ProtectSystem=strict，写目录被限制」，查了一圈，方向不对。
这类报错背后常见的原因有几处，逐个排除就行。PrivateTmp 会给服务挂一个独立的 /tmp，宿主机上的文件在服务里看不到。也可能是依赖的另一个服务没加同样的隔离，两边 /tmp 不是同一个。
还有一种情况，服务启动顺序在前的 tmpfiles 创建的文件也被隔离了。
第一件事是确认服务实际看到的 /tmp
systemctl show app -p PrivateTmp && ls -l /proc/$(pgrep -f app | head -1)/root/tmp再往下把套接字改到共享目录
grep -nE 'PrivateTmp|RuntimeDirectory' /etc/systemd/system/app.service然后用 RuntimeDirectory 提供共享路径
systemctl daemon-reload && systemctl restart app等前面都确认过，再确认套接字可访问
ss -xlp | grep app.sock恢复的判定其实很直接。服务启动不再报找不到套接字，ss 里能看到监听的 unix socket，两个服务之间通信恢复正常。
PrivateTmp 是安全加固里收益较高的一项，改造成本主要在路径约定；需要共享的文件放到 /run 下的 RuntimeDirectory 更规范。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。