Custodian：轻量级进程守护工具的设计原理与容器化实践

1. 项目概述：一个守护进程的诞生与价值

在软件开发和系统运维的日常工作中，我们常常会遇到一个经典问题：如何确保一个关键的服务进程能够“长生不老”？无论是处理实时数据流的后台程序、一个需要长期运行的定时任务脚本，还是一个对外提供API的微服务，它们的稳定运行都至关重要。然而，现实世界充满了不确定性——内存泄漏、未捕获的异常、底层依赖服务中断，甚至是操作系统本身的资源回收，都可能导致进程意外退出。手动重启不仅效率低下，更无法应对深夜或无人值守时的突发状况。这时，一个可靠、轻量且功能专一的“守护者”（Custodian）就显得尤为必要。

indigokarasu/custodian 正是这样一个项目。从名字就能直观感受到它的职责——“监护人”或“守护者”。它的核心使命就是监控并管理指定的子进程，在其异常退出时自动重启，保障服务的持续可用性。这听起来似乎很简单，市面上也有systemd、supervisord、pm2等成熟的方案，但 custodian 选择了一条不同的道路：极致轻量、零外部依赖、纯粹的 Unix 哲学实践。它通常被编译成一个静态链接的单一可执行文件，可以像一把瑞士军刀一样，被轻松地塞进任何容器镜像或最小化的服务器环境中，成为那个默默无闻却至关重要的“安全网”。

这个项目特别适合那些追求部署简洁性、对资源占用敏感，或者需要在受限环境（如 IoT 设备、早期阶段的容器化应用）中确保进程健康的场景。如果你厌倦了为一个小脚本配置复杂的systemd unit文件，或者不希望在一个轻量容器中引入Python和supervisord的整个运行时，那么 custodian 很可能就是你正在寻找的解决方案。接下来，我将深入拆解它的设计思路、核心实现、使用方法以及那些在实战中积累下来的宝贵经验。

1.1 核心需求与设计哲学解析

为什么需要再造一个进程守护工具？要理解 custodian 的价值，首先要看它瞄准的核心痛点。现有的主流方案在某些场景下存在“过重”或“过复杂”的问题。例如，systemd功能强大，但它是系统级的，与操作系统深度耦合，在容器内使用有时会显得笨重，且学习曲线较陡。supervisord功能丰富，配置灵活，但它本身是一个需要持续运行的 Python 进程，这意味着你需要先维护一个 Python 环境。对于使用 Go、Rust 等语言编写的、旨在输出单一静态二进制文件的应用来说，引入一个额外的、带有动态依赖的守护进程，在部署简洁性和安全性上是一种妥协。

Custodian 的设计哲学可以概括为“做一件事，并把它做好”。它将自己定位为一个纯粹的“进程生命周期管理器”，其功能边界非常清晰：

1. 启动子进程：根据给定的命令和参数启动目标程序。
2. 状态监控：持续跟踪子进程的运行状态。
3. 失败重启：当子进程非正常退出（例如，退出码非零）时，自动重新启动它。
4. 有限的重启策略：提供简单的重启策略（如延迟重启），防止在程序本身有致命错误时陷入“重启-崩溃”的死循环。
5. 信号传递：能够将接收到的系统信号（如 SIGTERM、SIGINT）优雅地传递给子进程，实现联动停止。

它刻意避免了诸如集群管理、Web管理界面、复杂的依赖管理、日志轮转等高级功能。这些功能固然有用，但也会引入复杂性、依赖和额外的故障点。Custodian 相信，这些功能应该由更上层的编排系统（如 Kubernetes、Docker Compose）或专门的日志工具（如logrotate、vector）来处理。这种“单一职责”的设计，使得 custodian 的核心代码非常紧凑，易于审计，运行时资源消耗极低，几乎可以忽略不计。

1.2 典型应用场景与生态位

理解了设计哲学，就能更准确地把握它的应用生态位。Custodian 并非要取代systemd或Kubernetes，而是在它们之下或之间，扮演一个更细粒度的、应用级别的守护角色。

场景一：容器内的进程守护。这是 custodian 最经典的应用场景。Docker 提倡“一个容器一个进程”，但这里的“进程”通常指的是“主进程”。如果你的应用主进程本身可能崩溃，或者你需要在容器内运行一个后台工作进程，那么直接作为ENTRYPOINT或CMD的进程一旦退出，容器就会停止。此时，将 custodian 作为容器的入口点，由它来启动和管理你的实际应用进程，就能轻松实现容器内进程的高可用。例如，一个 Python Web 应用容器，其Dockerfile的结尾可以是ENTRYPOINT [“/custodian”, “—“, “gunicorn”, “myapp:app”]。

场景二：简易服务部署与开发环境。在非容器化的服务器上，对于内部工具、小型 API 服务或定时任务脚本，你可能不想动用systemd。直接使用 custodian 配合一个简单的启动脚本，就能快速搭建一个具备基本自愈能力的服务环境。在开发阶段，你也可以用它来确保你的开发服务器在代码修改后（结合文件监控工具）或意外崩溃后能自动重启，提升开发体验。

场景三：嵌入式与资源受限环境。在树莓派、路由器或其它 IoT 设备上，系统资源非常宝贵。一个用 Go 编译的、只有几 MB 大小的 custodian 二进制文件，远比安装一套 Python 或配置完整的systemd来得经济。它能可靠地守护设备上的关键数据采集或控制进程。

场景四：作为复杂进程组的“粘合剂”。有时，一个服务可能需要按顺序或并行启动多个进程。虽然 custodian 本身不直接管理进程组，但你可以通过编写一个简单的 Shell 脚本作为“启动器”，然后让 custodian 守护这个脚本。脚本内部可以处理更复杂的进程间关系和逻辑。

注意：Custodian 不适合需要跨节点管理、服务发现、负载均衡、配置热更新等复杂功能的场景。对于这些需求，应直接考虑 Kubernetes、Nomad 等成熟的编排系统，或者 Consul、etcd 等服务网格方案。

2. 核心机制与实现原理深度拆解

要信任一个工具，尤其是负责“守护”关键进程的工具，必须理解其内部工作机制。Custodian 的实现充分体现了 Unix 编程的优雅与简洁，其核心围绕着进程创建、信号处理和状态机这几个基本概念展开。

2.1 进程监控与状态管理机制

Custodian 本身是一个独立的进程。当它启动时，会通过fork和exec系统调用创建目标子进程。此后，custodian 便进入一个监控循环。这个循环的核心是调用waitpid（或其跨平台等效系统调用）来等待子进程的状态变化。

waitpid是一个阻塞调用，它会暂停 custodian 进程的执行，直到其监控的子进程发生状态改变（退出、被信号停止等）。一旦子进程退出，waitpid会返回，并告知 custodian 子进程的退出状态码。Custodian 正是通过这个退出码来判断子进程的“健康”状况。

这里涉及一个关键策略：如何定义“异常退出”？大多数 Unix/Linux 程序约定，退出码为 0 表示成功（Success），非 0 表示失败（Failure）。Custodian 通常遵循这个约定。当它检测到子进程以非零退出码结束时，就会认为这是一次“失败”，从而触发重启逻辑。反之，如果子进程以 0 退出，custodian 可能会认为任务已成功完成，从而选择退出（取决于具体配置）。这对于运行一次性任务的场景很有用。

为了实现重启，custodian 在子进程退出后，会根据配置的延迟（例如，等待 2 秒以防止瞬时资源竞争或快速崩溃循环），再次执行fork和exec，生成一个新的子进程实例，并重新开始监控循环。这就构成了一个简单的“监控-重启”状态机。

2.2 信号传递与优雅终止

一个合格的守护进程管理器，必须能妥善处理系统信号，实现自身和子进程的优雅终止。这是保障数据一致性和系统稳定性的关键。

当用户向 custodian 进程发送SIGTERM（终止信号）或SIGINT（中断信号，通常由 Ctrl+C 触发）时，custodian 不会立刻自杀。相反，它会先捕获这个信号，然后将其转发（kill）给当前正在管理的子进程。这是一种“父进程通知子进程”的优雅关闭模式。

转发信号后，custodian 会进入一个等待期。它期望子进程在收到SIGTERM后，能够执行清理工作（如关闭数据库连接、写完日志、完成当前请求等），然后自行退出。Custodian 会继续调用waitpid等待子进程结束。只有在成功等到子进程退出后，custodian 自己才会退出。

如果子进程在预设的超时时间内（如果有配置）没有退出，custodian 可能会采取进一步措施，例如发送更强的SIGKILL信号（强制杀死）。这个过程确保了在关闭时，管理者和被管理者步调一致，避免了产生“孤儿进程”或强制杀死导致的数据损坏。

2.3 资源限制与隔离考量

虽然 custodian 项目本身可能不直接提供像cgroups那样复杂的资源隔离功能，但理解它与系统资源管理的关系很重要。在容器化环境中，资源限制（CPU、内存）通常由容器运行时（如 Docker）通过cgroups在容器层面进行设置。Custodian 和其子进程同属一个容器，共享相同的cgroup限制。

这意味着，如果你为容器设置了 512MB 的内存限制，那么 custodian 进程和它守护的子进程的内存总和不能超过这个限制。如果子进程发生内存泄漏，最终可能导致整个容器因 OOM（内存不足）而被内核杀死。此时，custodian 也会随之退出。在这种情况下，重启策略将由容器编排器（如 Docker 的restart policy或 Kubernetes 的restartPolicy）来决定，而不是 custodian 本身。

因此，在设计和部署时，需要明确责任边界：custodian 负责应对进程级的逻辑错误（如崩溃）；而系统级的资源约束和隔离，则应交给容器或操作系统层面的工具来处理。这种分工使得每个组件都能更专注、更高效。

3. 从零开始：编译、安装与基础配置

理论讲得再多，不如动手实践。让我们从获取和编译 custodian 开始，一步步掌握它的使用。

3.1 获取源码与编译构建

Custodian 是一个用 Rust 语言编写的项目，这赋予了它高性能、内存安全和轻松编译成静态二进制文件的特点。假设你已经安装了 Rust 的工具链（rustc和cargo），编译过程非常简单。

首先，克隆项目仓库：

git clone https://github.com/indigokarasu/custodian.git cd custodian

使用cargo进行编译。推荐使用--release标志来生成优化后的二进制文件，体积更小，运行更快：

cargo build --release

编译完成后，可执行文件位于target/release/custodian。你可以将其复制到系统的可执行路径下，例如/usr/local/bin/：

sudo cp target/release/custodian /usr/local/bin/

如果你想为其他平台交叉编译（例如，在 x86_64 的机器上编译出 arm64 架构的二进制文件以便在树莓派上运行），Rust 的交叉编译支持也非常出色。你需要安装对应的目标工具链，例如：

# 安装 ARM64 目标工具链 rustup target add aarch64-unknown-linux-gnu # 进行交叉编译 cargo build --release --target=aarch64-unknown-linux-gnu

编译出的文件将位于target/aarch64-unknown-linux-gnu/release/custodian。

实操心得：对于生产环境，我强烈建议在 CI/CD 流水线中完成编译，并将生成的静态二进制文件直接打包进容器镜像。这样做的好处是镜像层不包含编译环境和源码，更安全、更小巧。你可以使用多阶段构建的Dockerfile，第一阶段用 Rust 镜像编译，第二阶段仅拷贝最终的二进制文件到scratch或alpine这样的超小基础镜像中。

3.2 命令行参数详解与基础用法

Custodian 的配置主要通过命令行参数完成，遵循典型的 Unix 工具风格。让我们解析几个最常用的参数：

• -c, --command <COMMAND>：指定要守护的命令。这是最重要的参数。
• -a, --args <ARGS>：传递给命令的参数。可以多次使用此选项来指定多个参数。
• --：分隔符。在--之后的所有内容都会被视作要运行的命令及其参数。这是一种更常见的用法，可以避免解析歧义。
• -r, --restart-delay <SECONDS>：在进程退出后，等待多少秒再重启。默认值可能是 0 或 1。设置一个合理的延迟（如2秒）对于避免崩溃循环非常关键。
• -e, --exit-codes <CODES>：指定哪些退出码被认为是“成功退出”，custodian 在遇到这些退出码后将不再重启。默认通常只有0。例如，-e 0 -e 130表示退出码 0 和 130（通常由 SIGINT 触发）都算成功。
• -l, --log <PATH>：将 custodian 自身的日志输出到指定文件，而不是标准错误输出。

基础使用示例：

1. 守护一个简单的 Python HTTP 服务器：

   custodian -- python3 -m http.server 8080

   这条命令会启动 custodian，并由它来运行python3 -m http.server 8080。如果该 Python 服务器崩溃，custodian 会立即重启它。

2. 使用重启延迟和自定义成功退出码：

   custodian -r 5 -e 0 -e 130 -- my_batch_job.sh

   守护脚本my_batch_job.sh。如果脚本以 0 或 130 退出，custodian 就停止工作。如果以其他码退出，custodian 会等待 5 秒后重启脚本。

3. 将日志输出到文件：

   custodian -l /var/log/custodian.log -- /usr/local/bin/my_service --config /etc/service.conf

3.3 配置文件模式进阶使用

除了命令行参数，custodian 也可能支持（或未来支持）通过配置文件来定义更复杂的守护任务，例如守护多个进程。虽然当前核心版本可能更侧重命令行，但了解这种模式很有必要，很多类似工具都提供这种功能。

一个假设的 TOML 格式配置文件custodian.toml可能长这样：

[[programs]] name = “web_api” command = “/usr/local/bin/gunicorn” args = [“-w”, “4”, “-b”, “0.0.0.0:8000”, “myapp:app”] restart_delay = 2 success_exit_codes = [0, 130] log_file = “/var/log/custodian/web_api.log” [[programs]] name = “background_worker” command = “/usr/local/bin/celery” args = [“worker”, “–app=myapp.celery”, “–loglevel=info”] restart_delay = 5

然后使用custodian -c custodian.toml来启动。这种方式更利于管理复杂的、多服务的部署场景，配置可以纳入版本控制。

注意事项：务必查阅你所使用 custodian 版本的实际文档，确认其支持的配置方式。命令行模式是通用且最可靠的。如果项目本身不支持多进程守护，你可以通过编写一个启动脚本来实现，然后用 custodian 守护这个脚本。

4. 实战集成：在 Docker 容器中扮演入口点

将 custodian 集成到 Docker 容器中，是发挥其最大价值的经典模式。这里我们详细走一遍流程。

4.1 Dockerfile 编写最佳实践

目标是将 custodian 和你的应用一起打包，并让 custodian 作为容器的ENTRYPOINT。

Dockerfile 示例：

# 第一阶段：构建 custodian (也可使用预编译的二进制文件) FROM rust:1-slim AS builder WORKDIR /build RUN cargo new custodian-app WORKDIR /build/custodian-app # 假设我们将 custodian 源码放在当前构建上下文的 `vendor/custodian/` 目录下 COPY vendor/custodian ./src/ COPY Cargo.toml . # 修改 Cargo.toml 中的 package 名和路径指向 custodian RUN cargo build –release # 第二阶段：构建最终应用镜像 FROM debian:bookworm-slim # 安装应用运行时可能需要的库，例如对于 Python 应用 RUN apt-get update && apt-get install -y –no-install-recommends \ python3 python3-pip \ && rm -rf /var/lib/apt/lists/* WORKDIR /app # 从第一阶段拷贝编译好的 custodian 二进制文件 COPY –from=builder /build/custodian-app/target/release/custodian /usr/local/bin/custodian # 拷贝你的应用代码和依赖文件 COPY requirements.txt . COPY src/ ./src/ # 安装 Python 依赖 RUN pip3 install –no-cache-dir -r requirements.txt # 将 custodian 设置为入口点，并指定要运行的命令 ENTRYPOINT [“custodian”, “–“] # 默认命令：启动你的应用。可以被 `docker run` 的参数覆盖 CMD [“python3”, “src/main.py”]

关键点解析：

1. 多阶段构建：第一阶段专门用于编译 Rust 项目，得到一个干净的二进制文件。第二阶段使用轻量级基础镜像，只包含应用运行所需的必要环境，使得最终镜像体积最小化。
2. ENTRYPOINT 与 CMD 的配合：ENTRYPOINT定义了容器启动时固定执行的部分（custodian），而CMD提供了默认参数（你的应用命令）。这种组合非常灵活。当运行docker run my-image时，容器实际执行的是custodian — python3 src/main.py。用户也可以在运行时覆盖CMD，例如docker run my-image /bin/bash，这将变成custodian — /bin/bash，实现了 custodian 对交互式 shell 的守护（虽然这听起来有点奇怪，但语法上是合法的）。
3. 静态链接优势：Rust 默认生成静态链接的可执行文件，这意味着custodian二进制文件不依赖目标系统上的动态库，可以在几乎任何 Linux 环境下运行，兼容性极佳。

4.2 与容器编排器的协同工作

当容器运行在 Kubernetes 或 Docker Swarm 等编排平台时，需要理解 custodian 与平台原生重启策略的交互。

• Docker Restart Policy：你可以在运行容器时通过–restart标志，或在docker-compose.yml中设置重启策略（如always,on-failure）。这个策略是 Docker 守护进程层面的。如果 custodian 进程本身因为某种原因退出（例如，它遇到了一个不可恢复的错误，或者整个容器被 OOM 杀死），那么 Docker 会根据这个策略决定是否重启整个容器。而 custodian 负责的是容器内部其子进程的重启。两者是互补的：custodian 处理应用逻辑错误导致的快速重启，Docker 处理容器运行时级别的严重故障。
• Kubernetes Pod RestartPolicy：在 K8s 的 Pod 定义中，restartPolicy字段（默认为Always）作用类似于 Docker 的 restart policy。它决定 Pod 内的所有容器在退出后是否被 kubelet 重启。同样，custodian 管理的是 Pod 内其所在容器的主进程的重启。

一个常见的配置策略是：在容器层面使用 custodian 确保进程快速自愈，同时在编排器层面设置一个相对宽松的重启策略（如on-failure或Always），作为应对更底层故障的最后保障。这样可以形成多层次的高可用防护。

4.3 日志收集与监控配置

在容器化环境中，日志通常被收集到标准输出（stdout）和标准错误输出（stderr），然后由容器运行时或日志驱动（如json-file,journald,Fluentd）统一收集。当使用 custodian 时，需要确保应用日志能正确传递。

Custodian 本身不会干涉其子进程的 stdout/stderr。只要你的应用将日志打印到标准输出，那么日志就会从容器的标准输出流中流出，被 Docker 或 Kubernetes 捕获。这是最佳实践。

你需要关注的是 custodian自身的日志。通过-l参数可以将 custodian 的日志（如重启事件记录）重定向到文件。但在容器中，更常见的做法是让 custodian 也将自己的日志输出到 stderr，这样就能和业务日志一起被收集。这通常取决于 custodian 的默认行为或编译选项。

为了监控，你可以在应用中加入健康检查端点（如/health），并通过 Kubernetes 的livenessProbe和readinessProbe来探测。即使 custodian 保证了进程存在，健康检查也能确保应用在“进程活着但服务已僵死”的状态下被重启。

5. 高级话题：性能、安全与边界情况处理

当 custodian 用于生产环境时，我们需要考虑更多维度的因素。

5.1 资源开销与性能影响评估

Custodian 的资源开销极低。作为一个用 Rust 编写的、逻辑简单的程序，其内存占用通常在几 MB 到十几 MB 之间，CPU 使用率在空闲时几乎为零。主要的 CPU 消耗发生在创建子进程的瞬间，以及监控循环中。waitpid系统调用在子进程运行期间是阻塞的，不会消耗 CPU 周期。

因此，在绝大多数场景下，custodian 引入的性能开销可以忽略不计。它的主要价值在于提升了服务的可靠性，其成本远低于因服务中断带来的业务损失。

5.2 安全实践与权限最小化

安全方面，遵循“最小权限原则”：

1. 非 root 用户运行：绝不要在容器内以 root 用户运行 custodian 或其子进程。在Dockerfile中，创建非特权用户并切换。

   RUN groupadd -r appuser && useradd -r -g appuser appuser USER appuser ENTRYPOINT [“custodian”, “–“] CMD [“python3”, “src/main.py”]

2. 只读文件系统：如果应用不需要写入文件系统，在 Kubernetes Pod 安全上下文或 Docker 运行参数中，将根文件系统挂载为只读（readOnlyRootFilesystem: true）。
3. 限制能力：移除容器不需要的 Linux Capabilities（如NET_ADMIN,SYS_ADMIN）。
4. 扫描二进制文件：对引入的 custodian 二进制文件进行安全扫描，确保其来自可信的构建链，没有已知漏洞。

5.3 处理“僵尸进程”与子进程树

一个成熟的进程管理器必须妥善处理子进程树，防止产生“僵尸进程”。僵尸进程是已终止但其退出状态尚未被父进程读取的进程，会占用少量的内核资源。

Custodian 的核心监控循环waitpid正是为了“收割”其直接子进程，防止其僵尸化。但是，如果被守护的命令（子进程）又创建了自己的子进程（孙子进程），情况会复杂一些。

在 Unix 中，如果一个进程终止，它的所有子进程会成为“孤儿进程”，并被 init 进程（PID 1）收养。在容器里，PID 1 就是入口点进程（在这里是 custodian）。一个设计良好的 custodian 应该具备“进程组”或“会话”管理的意识，确保它能接收到孙子进程终止的信号，并进行正确的waitpid操作，或者至少能通过设置信号处理（如SIGCHLD处理为SIG_IGN）来让内核自动回收孤儿进程。

实操心得：在编写需要被 custodian 守护的应用程序时，一个良好的实践是确保应用自己能管理好其创建的所有子进程，并在退出前妥善等待它们结束。对于像 Shell 脚本这样容易衍生多进程的情况要格外小心。如果 custodian 的版本对进程组支持有限，一个变通方案是使用setsid或类似的工具，让你的应用在一个新的会话组中启动，这样更容易进行整体管理。

5.4 与 Systemd 的对比与选型建议

最后，我们系统性地对比一下 custodian 和 systemd，以帮助你在具体场景中做出选择。

选型建议：

• 选择 Custodian 当：你的场景是容器化部署；你需要一个零依赖、开箱即用的守护工具；你管理的服务非常简单，不需要 systemd 提供的那些高级功能（如套接字激活、复杂的依赖关系）；你对部署制品的体积和纯净度有极致要求。
• 选择 Systemd 当：你在管理物理机或虚拟机上的系统服务；你需要利用 systemd 强大的生态系统（如日志管理journald、资源控制cgroups、服务间依赖）；你的服务配置复杂，需要EnvironmentFile、ExecStartPre等高级特性。

6. 故障排查与经验实录

即使工具再简单，在实际使用中也会遇到各种问题。下面记录了一些典型问题及其排查思路。

6.1 常见问题速查表

6.2 调试技巧与日志分析

有效的日志是排查问题的生命线。你需要建立清晰的日志流：

1. 应用日志：确保你的应用程序将日志输出到标准输出（stdout）。这是云原生应用的标准做法，便于容器平台收集。
2. Custodian 日志：使用-l /proc/1/fd/1这个技巧可以将 custodian 的日志也重定向到容器的 stdout。因为/proc/1/fd/1指向容器 PID 1 进程（即 custodian）的标准输出文件描述符。或者，简单地将 custodian 的日志重定向到 stderr（如果其默认行为不是这样，可能需要修改源码或使用2>&1）。
3. 查看日志：使用docker logs <container_id>或kubectl logs <pod_name>来查看整合后的日志流。通过时间戳和日志内容，你可以清晰看到 custodian 在何时重启了进程，以及进程重启前后的应用日志，从而判断重启原因。

6.3 我踩过的坑与心得

• 重启风暴：曾经守护一个连接数据库的服务，没有设置restart-delay。数据库临时波动导致服务启动时连接失败立即崩溃，custodian 瞬间重启，又崩溃… 瞬间产生上百个重启记录，差点把日志系统塞满。教训：永远设置一个合理的重启延迟，至少 2-5 秒，这能给外部依赖（数据库、网络、其他服务）一个恢复的时间窗口。
• 信号屏蔽：有些应用（特别是某些 Java 应用或使用了某些框架的应用）会屏蔽SIGTERM信号。这导致docker stop时 custodian 转发了信号，但应用没反应，最终超时被SIGKILL强杀。解决方案：确保你的应用能响应SIGTERM。对于无法修改的第三方软件，可能需要编写一个包装脚本，在脚本中捕获信号并执行自定义的关闭逻辑。
• PID 1 的责任：在早期版本中，如果 custodian 作为容器 PID 1，对SIGCHLD信号的处理可能不够完善，导致孙子进程僵尸化。建议：使用最新版本的 custodian，并关注其关于进程收割的 Issue 和更新。如果问题依旧，一个终极方案是使用tini或dumb-init这类极简的 init 进程作为容器的ENTRYPOINT，然后让tini去运行custodian。即：ENTRYPOINT [“/tini”, “–“, “custodian”, “–“]。让专业的 init 进程来处理信号和僵尸进程回收，custodian 专注于业务进程守护。

indigokarasu/custodian 这个项目，以其极简的设计和单一专注的功能，在云原生和轻量级部署的生态中找到了一个稳固的位置。它不试图解决所有问题，而是把“进程守护”这一件事做到了简单、可靠、高效。当你下次需要为一个容器内的小服务、一个开发环境的后台任务，或者一个资源受限的嵌入式应用寻找“守护神”时，不妨给它一个机会。从编译一个不到 10MB 的静态二进制文件开始，你会体会到那种“工具恰好解决问题”的畅快感。