## 👻 Linux's Invisible Helpers: Daemons and Units {#sec-6e36ad82c8cb}

When operating a [[Linux]] system, you'll encounter countless 'daemons' running silently in the background. We manage them using a tool called `systemd`. What's the relationship between these two, and why do they have such distinctive names? Just as there's philosophy in a single line of code, the structure of a Linux system embodies clear design intentions.

![Image of systemd issuing work instructions to various daemons](/media/editor_temp/6/a66caf8f-e91b-4373-af97-e3f7158d0194.png "systemd가 여러 daemon에 작업지시를 내리는 이미지")

## 1. Why 'Daemon'? : The Clever Entities in the Background {#sec-facc962b0b1c}
The name 'daemon' originates from Greek mythology, referring to **'Daemons'**, benevolent supernatural beings who invisibly assisted between gods and humans. Later, influenced by physicist Maxwell's hypothesis of 'Maxwell’s Demon', MIT developers in 1963 adopted this name for **"programs that operate autonomously in the background without user intervention, making their own decisions and performing tasks."**

*   **Essence:** Daemons do not interact directly with users. Even if you close the terminal, they reside in memory, waiting for network requests or monitoring system status—they are, in essence, **'background processes'**.

## 2. Is systemd also a Daemon? : "The Master Daemon that Manages Daemons" {#sec-37340e1c3330}
Yes, it is. The **'d'** at the end of its name is the clue. `systemd` is the **first process (PID 1)** executed after the [[Linux]] kernel boots, acting as the **'master daemon'** that orchestrates and manages all other daemons.

Before `systemd`, [[Linux]] systems managed daemons in a disorganized manner. `systemd` emerged to bring order to this chaos, standardizing the management of all system elements. The standard specification introduced here is the **'Unit'**.

## 3. Units: The 'Standard Work Instructions' that Drive Daemons {#sec-c8112a55b96d}
If a daemon is the 'entity' that performs actual work, then **a Unit is the 'work instruction' detailing how to manage that entity.** The `systemd` master daemon reads these instructions (Units) we create and, according to their content, activates or deactivates individual daemons.

*   **Clarity of Intent:** Without the Unit specification, developers would write daemon execution code in disparate ways. However, thanks to the standard instruction set provided by Units (e.g., `.service` files), we can precisely and robustly define **"in what environment, in what order, and how to restart if a problem occurs."**
*   **Flexible Extensibility:** Units are not solely for daemons (Services). They treat all Linux elements, such as 'timers' for scheduled tasks and 'mounts' for connecting devices, using the same 'work instruction' format. This allows the entire system to be extended with a consistent logic.



## 4. Relationship at a Glance {#sec-ea68ba1a28f7}

| Category | Daemon | systemd Unit |
| :--- | :--- | :--- |
| **Identity** | An actual **process** running in memory | A **specification file** recording system configurations |
| **Role** | Performs actual functions in the background | Defines daemon execution conditions and behavior |
| **Analogy** | A **worker** silently performing tasks on-site | The **work instructions** that the worker follows |

> **To summarize:**   
> The `systemd` master daemon reads **Units (work instructions)** to direct numerous **daemons (workers)** to operate precisely according to defined rules. 


## 5. The Diverse Nature of Workers: Properly Distinguishing 'Daemons' and 'Service Units' {#sec-40ea0fcb27a7}

When we commonly say "start a service," the 'worker' (daemon) running in the background isn't limited to a single form. Any program, regardless of the language it's written in or its specific form, can become a daemon as long as it operates in the background.  

**Various Forms of Workers:**

- Script Daemons: If you register Python code you've written, such as Django or FastAPI applications, as a Unit, it becomes a Python daemon running via the `python3` interpreter.

- Binary Daemons: Programs like Nginx or `sshd`, pre-compiled in languages such as C or Go, are daemons that exist as executable files themselves.

- Shell Script Daemons: Even a simple `.sh` file, if running in a continuous loop in the background, can serve as an effective worker (daemon).

**Service Units are the 'Connecting Link':**

Strictly speaking, `sshd` or your Python script itself is not a 'service'. They are merely daemons (workers). The `.service` file (Unit) that we create in the `/etc/systemd/system/` directory, or that is automatically registered when a package is installed, is the work instruction that formally registers that worker as a component of the system.  

## Conclusion {#sec-5483f8db76f6}

A daemon refers to the state of a "program working in the background," while a service Unit is the standardized specification that allows `systemd`, the master, to control that daemon. It's thanks to these instructions that `systemd` can issue commands in the same way, regardless of whether the worker is a Python script or a binary.

What do you think? I've been using [[Linux]] as my primary OS for about 4-5 years, and even though I thought I understood the concepts of daemons and units, explaining them to someone else was always challenging. Perhaps I thought I knew, but hadn't fully grasped them. Now, having finally defined and organized them in my own words, my mind feels much clearer. 

Writing is indeed enjoyable. Even if it takes time, writing helps organize my thoughts.