/run 是 linux 系统为解决启动早期运行时数据存放问题而引入的 tmpfs 内存目录，替代 /var/run 以确保服务在 /var 未挂载时仍可写入 pid 和 socket；自 fhs 3.0 起，/var/run 仅为指向 /run 的符号链接。
/run 目录是 Linux 系统运行时数据管理方式演进的核心体现，它不是简单新增的一个目录，而是为解决早期启动阶段数据存放矛盾而产生的结构性调整。
/run 替代 /var/run 的根本动因
在 FHS 2.3 标准下，运行时数据（如 PID 文件、套接字）统一放在 /var/run。但 /var 通常挂载在独立磁盘分区上，系统启动早期可能尚未完成挂载——此时 sshd、systemd 等关键服务却急需写入 PID 或通信 socket，导致失败或被迫使用非常规路径（如 /dev/.udev、/dev/.systemd）。
- initramfs 阶段即可创建并挂载 /run（tmpfs），确保服务从启动第一秒起就有可写的运行时空间
- /var 分区延迟挂载、只读挂载或故障时，/run 仍能正常工作
- 避免将易失性数据混入本应长期保留的日志、缓存等 /var 内容中，职责更清晰
/run 的实际承载形式与行为特征
/run 是一个挂载在内存中的 tmpfs 文件系统，不是普通磁盘目录。这意味着：
- 所有内容随重启自动清空，无需清理脚本干预
- 不占用磁盘空间，但受内存和 swap 限制（可通过 /proc/sys/vm/vfs_cache_pressure 调整）
- 支持根文件系统以只读方式挂载——所有需写入的运行时状态都落在内存中
- 常见内容包括：服务 PID 文件（/run/sshd.pid）、D-Bus socket（/run/dbus/system_bus_socket）、udev 设备状态、systemd 运行时元数据、用户会话目录（/run/user/1000）
/var/run 的角色已完全退化为兼容层
自 FHS 3.0 起，/var/run 不再是独立存储位置，而是指向 /run 的符号链接：
- 执行 ls -l /var/run 通常看到 /var/run -> /run
- 该链接由发行版初始化脚本（如 systemd-firstboot 或 dpkg 触发的 postinst）自动建立
- 若缺失，部分老旧软件（尤其 shell 脚本或 LSB-compliant init 脚本）可能报错或降级使用非标准路径
- 手动向 /var/run 写入文件等同于写入 /run，但逻辑上不应绕过 /run 直接操作该链接
演变带来的实际影响与运维注意点
这一变化对日常使用透明，但在排查和服务定制时需明确边界：
- 编写服务脚本时，应优先使用 /run，而非硬编码 /var/run
- 调试服务启动失败，检查 /run 下对应 PID 或 socket 是否成功创建，比查 /var/run 更准确
- 容器或 chroot 环境中若未挂载 tmpfs 到 /run，systemd 或 udev 可能无法启动
- 监控磁盘空间时，/run 不计入 df 输出的磁盘用量，但需关注内存使用（df -h 显示 tmpfs 大小）
