## 👻 [[Linux]] 的幕后助手：Daemon 与 Unit {#sec-6e36ad82c8cb}

在操作 [[Linux]] 系统时，我们会发现有无数的“守护进程”（Daemon）在后台默默运行。而我们则通过 `systemd` 这个工具来管理它们。那么，这两者之间究竟有何关联？为何会拥有如此独特的名称？正如每一行代码都蕴含着哲学思想，[[Linux]] 系统的架构也承载着清晰的设计意图。

![Linux Daemon 和 systemd 概念图](/media/editor_temp/6/a66caf8f-e91b-4373-af97-e3f7158d0194.png "systemd 向多个 daemon 发送工作指令的示意图")

## 1. 为何称作“守护进程”（Daemon）？：幕后聪明的存在 {#sec-facc962b0b1c}
“守护进程”（Daemon）这个名称源于希腊神话中那些在神与人之间提供无形帮助的**“守护神”（Daemons）**。随后，它又经历了物理学家麦克斯韦提出的“麦克斯韦妖”（Maxwell’s Demon）假说，最终在1963年，麻省理工学院（MIT）的开发者们将此名赋予了**“无需用户干预，在后台自主判断并执行任务的程序”**。

*   **本质：** 守护进程不直接与用户交互。即使关闭终端，它们仍驻留在内存中，等待网络请求或监控系统状态，它本身就是一种**“后台进程”**。

## 2. systemd 也是守护进程吗？：“管理守护进程的主守护进程” {#sec-37340e1c3330}
是的，没错。名称末尾的**“d”**便是其证据。`systemd` 是 [[Linux]] 内核启动后第一个运行的**进程（PID 1）**，同时也是一个**“主守护进程”**，负责调度和管理所有其他守护进程。

在此之前，[[Linux]] 管理守护进程的方式可谓是五花八门，缺乏统一性。`systemd` 的出现旨在平息这种混乱，以**标准化规范**来管理所有系统要素。而这里所说的标准化规范，正是**“单元”（Unit）**。

## 3. Unit：驱动守护进程的“标准工作指令书” {#sec-c8112a55b96d}
如果说守护进程是实际执行任务的“实体”，那么**单元（Unit）则是指导如何操作这些实体的“工作指令书”**。`systemd` 这个主守护进程会读取我们编写的指令书（Unit），并根据其内容来启动或停止各个守护进程。

*   **意图明确性：** 如果没有单元这种规范，每位开发者可能会以各自的方式编写启动守护进程的代码。但有了单元（例如：`.service` 文件）这一标准指令书，我们就能非常精细且稳固地定义**“在何种环境下、以何种顺序、出现问题时如何重启”**。
*   **灵活的扩展性：** 单元不仅限于守护进程（Service）。它以相同的“工作指令书”形式处理 [[Linux]] 中的所有元素，例如在特定时间执行任务的“定时器”（timer）、连接设备的“挂载点”（mount）等。这使得整个系统能够以一致的逻辑进行扩展。



## 4. 关系一览 {#sec-ea68ba1a28f7}

| 类别 | 守护进程 (Daemon) | systemd 单元 (Unit) |
| :--- | :--- | :--- |
| **本质** | 在内存中实际运行的**进程** | 记录系统配置的**说明文件** |
| **作用** | 在后台执行实际功能 | 定义守护进程的运行条件和工作方式 |
| **比喻** | 在现场默默工作的**工人** | 工人遵循的**工作指令书** |

> **总结来说：**   
> `systemd` 这个主守护进程通过读取**单元（工作指令书）**，指挥众多**守护进程（工人）**按照既定规则精确地运行。 


## 5. “工人”身份多样：正确区分“守护进程”与“服务单元” {#sec-40ea0fcb27a7}

当我们常说“启动服务”时，实际在后台运行的“工人”（守护进程）并非只有一种形态。因为无论用何种语言编写，以何种形式存在，只要能在后台运行，都可以成为守护进程。

**“工人”的多种形态：**

- 脚本守护进程：将您自己编写的 Django 或 FastAPI 等 Python 代码注册为单元，它就会通过 python3 执行器运行，成为一个 Python 守护进程。

- 二进制守护进程：用 C 或 Go 语言预编译的 Nginx、sshd 等程序，它们本身就是可执行文件形式的守护进程。

- Shell 脚本守护进程：即使是一个简单的 .sh 文件，只要它在后台无限循环运行，也能成为一个优秀的“工人”（守护进程）。

**服务单元是“连接纽带”：**

严格来说，sshd 或您的 Python 脚本本身并非“服务”。它们只是守护进程（工人）。
我们直接在 `/etc/systemd/system/` 目录下创建的，或在安装软件包时自动注册的 `.service` 文件（单元），才是将这些“工人”注册为系统正式成员的工作指令书。

## 结论 {#sec-5483f8db76f6}

守护进程指的是“在后台运行的程序”这一状态，而服务单元（Service Unit）则是将守护进程规范化，使其能够被 `systemd` 这个主进程控制的说明文件。正是因为有了这份指令书，`systemd` 才能以相同的方式向“工人”发出指令，无论这些“工人”是 Python 脚本还是二进制程序。

您觉得如何？我使用 [[Linux]] 作为主要系统已经有四五年了，即使自认为理解了守护进程和单元这两个概念，但在向他人解释时却发现非常困难。或许我只是自以为懂了，实际上并未完全理解。如今，终于能用自己的语言进行定义和整理，感觉思路清晰了许多。

写作果然很有趣。虽然耗费时间，但写着写着，思绪便会变得井然有序。