/run/systemd空间不足需通过修改/etc/fstab增大tmpfs挂载大小解决，如添加“tmpfs /run tmpfs nosuid,noexec,size=24M,nr_inodes=4096 0 0”并重启生效。
/run 是一个 tmpfs 类型的内存文件系统，默认由内核按物理内存比例自动分配大小（通常为 RAM 的 50% 或固定上限，如 12–64MB），但某些小内存设备（如 128MB 的 VPS）上它可能被设得过小，导致 /run/systemd 下空间不足，进而引发 systemd 服务注册失败、软件安装中断等报错。
/run/systemd 空间不足的典型表现
错误信息中明确出现类似提示：
- Failed to reload daemon: Refusing to reload, not enough space available on /run/systemd
- Currently, X.XM are free, but a safety buffer of Y.YM is enforced
- 安装 dnsmasq、nginx、docker 等服务时，
Created symlink … → …后立即报 reload 失败
此时运行 df -h /run 会显示可用空间远低于 systemd 要求的安全余量（默认约 16MB）。
临时验证与快速释放（不重启）
可先尝试手动释放 /run 下部分缓存（仅限 tmpfs 可写场景）：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 检查当前挂载参数：
mount | grep "/run "，确认是否为 tmpfs 且可读写 - 若发现 /run 下有大量临时 socket、pid 文件残留（如旧服务未清理的
/run/systemd/private或/run/docker.sock），可安全删除已终止进程对应的文件（注意勿删正在运行服务的） - 重启 systemd-manager（谨慎）：
sudo systemctl kill --signal=SIGUSR2 systemd-journald，有时能触发日志管理器释放内部缓冲
但该方式治标不治本，尤其在极小内存设备上效果有限。
永久解决：调整 /run 的 tmpfs 挂载大小
核心方法是修改 /etc/fstab，显式指定 /run 的大小。例如将默认约 12MB 提升至 18–24MB：
- 执行：
echo "tmpfs /run tmpfs nosuid,noexec,size=24M,nr_inodes=4096 0 0" | sudo tee -a /etc/fstab - 注意：必须保留原有
/run行（如有），或先注释掉旧行再追加新行；size=值建议不低于 16M，上限不宜超过物理内存的 10%（如 512MB 内存可设 48M） - 生效方式：重启系统（最稳妥），或卸载重挂（风险较高，可能中断依赖 /run 的服务）：
sudo mount -o remount /run（部分系统支持，但 systemd 可能拒绝）
其他关联注意事项
避免因 /run 空间问题引发连锁反应：
-
不要盲目清空 /run：它是运行时目录，包含 socket、pid、runtime state，直接
rm -rf /run/*会导致多数服务崩溃 -
检查 journald 日志位置：默认 journal 存于
/run/log/journal（易占满 /run），可改用持久化存储：sudo mkdir -p /var/log/journal && sudo systemd-tmpfiles --create，再重启 journald -
容器环境特别留意：Docker/Podman 默认在 /run 中创建 sock 和 runtime 目录，小内存 VPS 建议配置
--default-runtime或限制容器资源，防止瞬时撑爆 /run
不复杂但容易忽略。关键就是让 /run 有足够余量容纳 systemd 的元数据和运行时对象，而不是靠反复清理或硬重启来掩盖容量设计缺陷。
