Nitro是一款小巧灵活的进程管理工具，适用于Linux系统的init进程或容器环境。它通过目录中的脚本进行配置，默认路径为/etc/nitro。Nitro具有高效的事件驱动机制，运行时无需内存分配，支持可靠的服务重启和日志记录，且不依赖系统时钟。它还可作为无权限的守护进程在POSIX系统上运行，适用于嵌入式、桌面或服务器等多种场景。

Nitro：轻量灵活的初始化系统与进程管理器

Nitro 是一款小巧的进程管理器，也可作为 Linux 系统的 PID 1（初始化进程）使用。它主要适用于以下场景：

1. 作为嵌入式设备、桌面或服务器的 Linux 初始化系统。
2. 作为 Linux initramfs 的初始化系统。
3. 作为 Linux 容器（如 Docker、Podman、LXC、Kubernetes）的初始化系统。
4. 作为 POSIX 系统上的非特权守护进程管理器。

Nitro 通过脚本目录进行配置，默认路径为 /etc/nitro，也可通过命令行参数指定。

核心优势

• 内存状态管理：所有状态保存在内存中，适用于只读根文件系统。
• 高效事件驱动：无轮询操作，运行时零内存分配，无文件描述符滥用。
• 简洁易用：单一自包含二进制文件，服务配置无需编译，服务目录包含简单脚本即可。
• 可靠的服务重启与日志机制：支持服务日志链，系统时钟不准确时仍可正常运行。
• 跨平台支持：可在 FreeBSD 上运行，使用 musl libc 时生成极小的静态二进制文件。

服务配置

在 /etc/nitro 或自定义服务目录中，每个目录可包含以下文件：

• setup：服务启动前执行的可选脚本，必须返回状态 0 才能继续。
• run：运行服务的主脚本，服务运行时该脚本不得退出。若无此脚本，服务被视为“一次性”服务。
• finish：服务结束后执行的可选脚本，接收 run 进程的退出状态和终止信号作为参数。
• log：符号链接到其他服务目录，用于将 run 的标准输出连接到日志服务的标准输入。
• down：存在时，Nitro 默认不启动该服务。
• 以 @ 结尾的服务目录被忽略，可用于参数化服务。

特殊服务

• LOG：为没有 log 符号链接的服务提供默认日志服务。
• SYS：SYS/setup 在其他服务启动前运行，SYS/finish 在系统关闭前运行，SYS/final 在所有进程终止后运行。SYS/fatal 和 SYS/reincarnate 分别用于处理致命错误和实现 initramfs。

参数化服务

以 @ 结尾的服务目录可通过符号链接或 nitroctl 手动启动，参数部分作为脚本的第一个参数传递。

操作模式

Nitro 的生命周期分为三个阶段：

1. 系统启动：先运行 SYS/setup，然后启动所有未标记为 down 的服务。
2. 服务管理：服务退出后自动重启，若重启过快则等待 2 秒。
3. 系统关闭：通过 nitroctl Reboot 或 nitroctl Shutdown 关闭系统，先运行 SYS/finish，然后发送 SIGTERM 信号，7 秒后发送 SIGKILL 信号，最后运行 SYS/final。

控制工具

nitroctl 用于远程控制 Nitro 实例，支持的命令包括启动、停止、重启服务，发送信号，以及系统关机和重启等。

跨平台支持

• Linux：Nitro 可作为 PID 1 直接启动，支持 Ctrl-Alt-Delete 触发有序重启。
• Docker 容器：静态编译的 Nitro 可轻松复制到容器中，/run 目录必须存在以使用默认控制套接字。
• FreeBSD：可通过 /etc/ttys 配置由 FreeBSD init 管理的 Nitro。

作者与致谢

Nitro 由 Leah Neukirchen 开发，灵感来源于 daemontools、freedt、runit、perp 和 s6 等系统。Nitro 采用 0BSD 许可证发布。

Nitro 以其轻量、灵活和跨平台的特性，成为现代系统管理的理想选择。

评论主要围绕Nitro init系统的功能、与其他系统的比较、命名问题以及适用场景展开。以下是总结：

1. 与其他init系统的比较：

   • 多位评论者将Nitro与runit、s6和dinit进行比较，关注其功能差异。例如，Nitro支持参数化服务，且为单一二进制文件，而runit则有多个二进制文件。
     • "One contrasting feature is parametrized services: several similar processes (like agetty) can be controlled by one service directory; I find it neat."（与runit相比，Nitro的一个显著特点是参数化服务：多个类似进程（如agetty）可以由一个服务目录控制；我觉得这很巧妙。）
     • "How does this compare to s6? I recently used it to setup an init system in docker containers & was wondering if nitro would be a good alternative."（与s6相比如何？我最近用它来设置Docker容器中的init系统，想知道Nitro是否是一个好的替代品。）

2. 命名问题：

   • 评论者指出Nitro与AWS Nitro和Node.js的Nitro引擎存在命名冲突，建议改名。
     • "The name & function overlap with AWS Nitro is severe."（Nitro与AWS Nitro的名称和功能重叠严重。）
     • "I'd recommend changing names, nitro is already a semi-popular server engine for node.js."（我建议改名，Nitro已经是Node.js中一个半流行的服务器引擎。）

3. 适用场景：

   • 有评论者对在容器中使用init系统表示疑虑，认为应更直接地设计为适用于Kubernetes或云环境。
     • "I'm always torn when I see anything mentioning running an init system in a container."（每当看到在容器中运行init系统的内容时，我总是感到矛盾。）
     • "It's probably just one of those 'people are going to do it anyway' things."（这可能是那种“人们无论如何都会去做”的事情之一。）

4. 技术实现与创新：

   • 评论者提到Nitro的简洁性和安全性，以及其在NixOS中的潜在应用。
     • "At Distrust, we wrote a dead simple init system in rust that is used by a few clients in production with security critical enclave use cases."（在Distrust，我们编写了一个非常简单的Rust init系统，被一些客户用于生产中的安全关键隔离用例。）
     • "This will be a game changer for porting to NixOS to new init systems, and even new kernels."（这将是向NixOS移植新init系统甚至新内核的游戏规则改变者。）

总结：Nitro init系统在功能、命名和适用场景上引发了广泛讨论，评论者对其与其他系统的比较、命名冲突以及在容器中的使用提出了不同看法，同时也对其技术实现和潜在应用表示认可。