服务一启动就显示status=233/RUNTIME_DIRECTORY，应用日志可能一行都没有。此时应该先看systemd为进程准备运行目录时遇到的错误，再决定是改服务配置，还是处理路径冲突。
233代表启动卡在哪一步
systemd将233定义为设置运行目录失败。对系统服务，RuntimeDirectory=myapp对应/run/myapp；用户服务的基目录则由$XDG_RUNTIME_DIR决定。日志里的底层错误比退出码更能指向原因，先区分路径不是目录、只读挂载、空间不足或权限限制。
把配置和磁盘上的路径对照起来
运行systemctl cat myapp.service查看主文件和覆盖项，再用systemctl show myapp.service -p RuntimeDirectory -p RuntimeDirectoryMode -p User -p Group确认管理器当前读取的值。用journalctl -u myapp.service -b -n 80 --no-pager找启动失败前后的消息。
系统服务可用namei -l /run/myapp逐级查看路径，用findmnt -T /run、df -h /run和df -i /run检查挂载和容量。若日志指向容器或安全策略，先确认运行环境允许准备该目录。
用专属目录消除冲突
应用只需要保存PID文件或Unix套接字时，用sudo systemctl edit myapp.service创建覆盖项，在[Service]下配置RuntimeDirectory=myapp与适合访问方的RuntimeDirectoryMode=0750。应用和客户端套接字路径也要对应更新。
名称用相对路径，不把/run/myapp整个路径填进RuntimeDirectory=。已有冲突文件时先查归属和业务依赖，确认可迁移再处理。避免递归改整个/run的权限；systemd可能递归调整指定目录树的所有权，因此目录应由单个服务专用。
运行文件和持久数据分开存放
RuntimeDirectory=从systemd 211起提供；较新的保留或路径扩展语法须对照本机man systemd.exec。默认服务停止会清理运行目录，重启机器后也不能依赖/run保存旧文件。数据库、上传文件等持久数据应放在经过规划的持久目录，可评估本机支持的StateDirectory=。
重启后验证实际访问方
变更后用systemd-analyze verify myapp.service检查配置，执行sudo systemctl daemon-reload再按维护计划启动或重启。检查systemctl is-active myapp.service和目录属主、模式；若应用监听Unix套接字，还要用实际调用账户发出健康请求。
可在萤光云或LightNode的隔离VPS复现路径被普通文件占用的场景。验收看启动日志不再出现233，且服务和实际客户端均能使用约定的目录或套接字。
FAQ
手动mkdir能长期修好吗？ 目录生命周期应由单元管理；手工创建最多帮助确认问题。
用户服务也在/run/myapp吗？ 用户服务从$XDG_RUNTIME_DIR下查找。
可以给目录777权限吗？ 不建议，按服务和真实调用方所需权限设置。
chmod能修复只读挂载吗？ 不能；先确认底层挂载和容器限制。
目录创建后服务仍失败呢？ 查看新的退出码和应用日志，故障可能已进入后续启动阶段。
温馨提示
不要移动正在被其他服务使用的套接字。共享路径先确认全部消费者，再改配置并记录回滚时需要恢复的路径和权限。
