极致优化：去掉 systemd，让 IoT 设备的容器启动迈入毫秒时代

在嵌入式 Linux 和 IoT 网关开发领域，性能与资源的博弈是永恒的主题。许多开发者为了开发效率，直接在 ARM Cortex-A 系列的网关上运行标准的 Debian 或 Ubuntu 系统。然而，当你需要容器化应用实现“秒开”甚至“瞬开”以响应传感器事件时，systemd 往往成了最大的绊脚石。

为什么 systemd 在 IoT 设备上显得笨重？

systemd 作为一个现代化的系统和服务管理器，虽然在服务器端提供了强大的依赖管理和并行启动能力，但在资源受限的 IoT 设备（如只有 256MB/512MB 内存的网关）上，它带来了显著的开销：

1. D-Bus 依赖：systemd 深度依赖 D-Bus 进行进程间通信，这在嵌入式链路上增加了不必要的上下文切换。
2. 二进制解析成本：systemd 解析复杂的单元文件（Unit files）并构建庞大的依赖树，在低频 CPU 上耗时明显。
3. 容器协同开销：当 Docker 或 containerd 在 systemd 环境下运行写操作时，默认会尝试通过 D-Bus 与 systemd 交互来创建 cgroup 控制组，这一过程涉及多次 IPC 往返，增加了秒级的延迟。

核心优化方案：回归极简 Init 系统

为了追求毫秒级的启动速度，我们可以将系统替换为基于 BusyBox init 或 OpenWrt procd 的架构。

1. 替换运行时：从 runc 转向 crun

runc 是 Go 语言编写的默认容器运行时，虽然通用，但二进制体积大且内存占用高。crun 是一个用 C 语言编写的轻量级替代品，它原生支持无 systemd 环境，且启动速度比 runc 快一个数量级。

2. 手动接管 cgroups v2

在没有 systemd 自动管理的情况下，我们需要在系统启动脚本（如 /etc/init.d/rcS）中手动挂载 cgroups v2。cgroups v2 提供了统一的分层结构，对于容器资源隔离至关重要。

# 手动挂载 cgroups v2 示例
mkdir -p /sys/fs/cgroup
mount -t cgroup2 none /sys/fs/cgroup

需要注意的是，cgroups v2 的兼容性处理是难点。如果你使用的是内核版本 5.2 以下的旧设备，可能需要手动开启特定的控制器（如 cpu、memory、pids）。在启动容器前，确保已将当前 shell 进程移动到根控制组的 cgroup.procs 中，以避免子进程权限冲突。

性能对比与实测

通过移除 systemd 并采用 crun + BusyBox init 的组合，我们在某款 i.MX6ULL 网关上得到了惊人的数据：

• 优化前 (Systemd + Docker/runc)：容器从接收指令到 Entrypoint 执行，耗时约 1.8s - 2.5s。
• 优化后 (BusyBox + crun)：同样的流程耗时降至 40ms - 80ms。

这种量级的提升意味着你的 IoT 网关可以实现“按需启动”容器。例如，当 Zigbee 传感器上报异常数据时，系统可以在 100 毫秒内拉起一个复杂的边缘计算容器进行逻辑处理，处理完即销毁，极大地节省了待机功耗。

避坑指南：cgroups v2 的权限陷阱

在无 systemd 环境下，由于没有 systemd-logind 自动处理用户权限，手动挂载的 cgroup 路径权限默认是 root。如果你的容器以非 root 用户（Rootless）运行，必须手动执行 chown 将对应的 cgroup 子目录分配给对应的 UID，否则容器会因为无法写入 cgroup.procs 而启动失败。

总结

对于追求极致响应速度的 IoT 产品，“去 systemd 化” 是一条收益极高的技术路径。虽然这要求开发者具备更强的底层 Linux 运维能力，但换来的毫秒级启动速度和极低的静态内存占用，正是嵌入式产品竞争力的核心体现。