Linux：systemd进程管理【1】

整体理解

要快速掌握Linux的systemd并覆盖80%的使用场景，以下是最重要的20%知识点：

Systemd简介与核心功能：
- Systemd是一个系统和服务管理器，作为Linux系统的PID 1进程，负责启动和管理其他系统组件。
- 它提供并行启动服务的能力，显著加快系统启动时间。
- Systemd使用socket和D-Bus激活服务，按需启动守护进程，并跟踪使用Linux控制组的进程。
- 它还维护挂载和自动挂载点，实现基于依赖的服务控制逻辑，并支持SysV和LSB init脚本。
核心组件：
- systemctl：Systemd的主命令行工具，用于控制服务和系统状态。
- systemd-journald：负责日志数据的收集和存储。
- systemd-analyze：用于分析系统启动性能和诊断性能问题。
- systemd-tmpfiles：创建、删除、清理临时和易失文件。
服务管理：
- 服务是systemd中代表后台进程或守护进程的单元，通过systemctl命令管理服务的启动、停止、重启和状态检查。
日志管理：
- Systemd集成了journald日志系统，提供了统一的日志管理解决方案，可以通过journalctl命令进行日志查询。
依赖管理和并行化处理：
- Systemd自动处理服务间的依赖关系，并并行启动服务，加快系统启动。
配置文件格式：
- Systemd使用unit文件（如.service）来·管理服务配置，这些文件位于/etc/systemd/system和/lib/systemd/system目录下。
系统启动和目标：
- Systemd支持多个运行级别（targets），如multi-user.target和graphical.target，用于定义不同的系统启动状态。
网络管理：
- systemd-networkd用于网络接口的设置和管理，而systemd-resolved提供网络名称解析服务。

掌握这些核心概念和工具，你将能够有效地管理和优化Linux系统上的服务和资源。

unit概念的理解

要快速掌握systemd中的unit并覆盖80%的使用场景，以下是最重要的20%知识点：

Unit的概念：
- Unit是systemd管理系统资源的基本单元，每个系统资源就是一个Unit，并使用一个Unit文件定义。
Unit的类型：
- Service unit（.service）：用于定义系统服务。
- Target unit（.target）：用于模拟实现“运行级别”。
- Device unit（.device）：用于定义内核识别的设备。
- Mount unit（.mount）：定义文件系统挂载点。
- Socket unit（.socket）：用于标识进程间通信用到的socket文件。
- Snapshot unit（.snapshot）：管理系统快照。
- Swap unit（.swap）：用于标识swap设备。
- Automount unit（.automount）：定义文件系统自动挂载点。
- Path unit（.path）：用于定义文件系统中的一个文件或目录。
Unit文件结构：
- Unit文件通常包含三个配置区段：Unit和Install段（所有Unit文件通用），Service段（仅服务类型的Unit文件特有）。
- Unit段包含服务的描述、依赖等信息，如Description、After、Requires等。
- Service段包含服务的具体管理和操作方法，如ExecStart、ExecStop等。
- Install段定义了Unit如何随系统启动，如WantedBy指定启动目标。
Unit文件的位置：
- Unit文件通常位于/etc/systemd/system、/run/systemd/system和/usr/lib/systemd/system三个目录中，其中/etc/systemd/system中的文件具有最高优先级。
管理Unit的命令：
- systemctl start|stop|restart|reload <unit>：启动、停止、重启、重载服务。
- systemctl enable|disable <unit>：设置服务开机自启或不自启。
- systemctl status <unit>：查看服务状态。
- systemctl list-units：列出所有已加载的units。

掌握这些核心概念和操作，你将能够有效地管理和配置Linux系统中的systemd units。

UNIT示例

编写一个systemd service unit文件需要遵循一定的格式和包含必要的指令。下面是一个基本的systemd service unit文件的编写步骤和示例：

1. 确定文件位置和名称

通常，自定义的service unit文件应该放在/etc/systemd/system/目录下。文件名通常以.service结尾，例如myapp.service。

2. 编写Unit文件

一个典型的systemd service unit文件包含三个部分：[Unit]、[Service]和[Install]。以下是每个部分的基本指令和说明：

[Unit] 部分

Description：服务的描述。
After：指定服务启动的顺序，依赖于哪些服务。
Requires：指定服务必须依赖的服务，如果这些服务失败，则当前服务也会失败。
Wants：指定服务希望启动的服务，但不是必需的。

[Service] 部分

Type：服务类型，如simple、forking、oneshot等。
ExecStart：启动服务时执行的命令。
ExecStop：停止服务时执行的命令（可选）。
Restart：服务失败时的重启策略，如on-failure。
User：运行服务的用户。
WorkingDirectory：服务的工作目录。

[Install] 部分

WantedBy：指定服务应该被哪些target依赖，通常是multi-user.target或graphical.target。

3. 示例

下面是一个简单的systemd service unit文件示例，它定义了一个名为myapp.service的服务：

[Unit]
Description=My Custom Application Service
After=network.target[Service]
Type=simple
ExecStart=/usr/bin/myapp
Restart=on-failure
User=myappuser
WorkingDirectory=/home/myappuser[Install]
WantedBy=multi-user.target

4. 启用和启动服务

编写完unit文件后，你需要执行以下命令来启用服务，并在系统启动时自动启动：

sudo systemctl daemon-reload
sudo systemctl enable myapp.service
sudo systemctl start myapp.service

systemctl daemon-reload：重新加载systemd的配置文件，使新添加的unit文件生效。
systemctl enable myapp.service：将服务设置为开机自启。
systemctl start myapp.service：启动服务。

5. 检查服务状态

使用以下命令检查服务的状态：

sudo systemctl status myapp.service

通过遵循这些步骤，你可以创建自己的systemd service unit文件，并管理自定义服务。

守护进程

守护进程（Daemon）是Linux系统中的一种后台运行的特殊进程，通常用于提供持续的服务或等待处理某些请求。以下是掌握守护进程最重要的20%知识点，帮助你快速学习并覆盖80%的使用场景：

守护进程的定义和作用：
- 守护进程是一种在后台运行的进程，不与任何终端相关联，通常用于执行特定的系统任务或服务。
守护进程的特点：
- 它们通常在系统启动时启动，并一直运行直到系统关闭。
- 守护进程通常在后台运行，不与用户直接交互。
- 它们通常被设计为长时间运行，并且能够处理多个请求。
常见的守护进程：
- sshd：提供SSH服务，允许远程登录。
- httpd 或 nginx：提供Web服务。
- crond：定时执行任务。
- syslogd：日志系统服务。
守护进程的启动方式：
- 守护进程可以通过init系统（如System V init）、systemd或Upstart等系统和服务管理器启动。
- 它们也可以通过配置文件（如/etc/init.d/下的脚本）启动。
守护进程的进程管理：
- 守护进程通常在/var/run目录下创建一个PID文件，记录其进程ID。
- 使用ps、top或htop命令可以查看守护进程的状态。
守护进程的日志记录：
- 守护进程通常将日志发送到syslog或直接写入到特定的日志文件中。
守护进程的配置文件：
- 守护进程的配置文件通常位于/etc目录下，例如/etc/httpd/conf/httpd.conf。
守护进程的安全性：
- 守护进程需要正确配置权限，以防止未授权访问。
- 使用防火墙和安全策略来保护守护进程。
守护进程的调试：
- 使用strace跟踪系统调用，帮助调试守护进程。
- 查看守护进程的日志文件以诊断问题。
守护进程的监控和维护：
- 使用systemctl或service命令管理守护进程的启动、停止和重启。
- 定期检查守护进程的状态和日志，确保其正常运行。

掌握这些关键知识点，你将能够理解和管理Linux系统中的守护进程，以及如何配置和维护它们以提供持续的服务。

unit的service中service部分type类型

在systemd的unit文件中，Service部分的Type指令定义了服务的启动类型，这对于服务的行为至关重要。以下是Type指令最重要的20%知识点，帮助你快速掌握并覆盖80%的使用场景：

simple：
- 这是默认的类型，适用于大多数服务。ExecStart指定的命令会直接启动服务，systemd会监控其主进程。
forking：
- 适用于传统的Unix服务，这些服务会fork出一个子进程来运行实际的服务，而父进程会立即退出。systemd需要知道服务已经forked，因此需要在服务启动后发送一个SIGTERM信号来通知systemd。
oneshot：
- 用于那些只执行一次的服务，比如某些初始化脚本。systemd会在ExecStart命令执行完成后立即认为服务已经启动。
dbus：
- 用于依赖于D-Bus的服务。systemd会等待D-Bus上指定的名字出现后才认为服务已经启动。
notify：
- 类似于simple，但是服务需要在启动后发送一个通知信号给systemd，告知它已经准备好接收请求。
idle：
- 服务只有在系统中没有其他任务执行时才会运行。
background：
- 类似于simple，但是systemd会立即返回，不会等待服务的启动。
foreground：
- 服务必须保持在前台运行，类似于simple，但是systemd会等待服务的控制终端变为前台进程。

了解这些Type类型及其适用场景，可以帮助你正确配置systemd服务，确保服务按照预期行为启动和运行。每种类型都有其特定的用途和配置要求，正确选择和配置Type对于服务的稳定性和可靠性至关重要。

sigterm信号

要快速掌握SIGTERM信号的80%使用场景，以下是最重要的20%知识点：

SIGTERM的定义：
- SIGTERM（Signal Termination）信号是一个请求进程终止的信号。它是kill命令的默认信号，用于告诉进程优雅地结束。
SIGTERM的作用：
- SIGTERM允许进程有机会执行清理操作，如关闭文件描述符、释放资源和保存状态，然后退出。
SIGTERM与SIGKILL的区别：
- 与SIGKILL不同，SIGTERM是可以被捕获和处理的，允许进程有机会执行清理操作。SIGKILL是不能被捕获的，用于立即终止进程。
SIGTERM的默认行为：
- 如果进程没有处理SIGTERM信号，其默认行为是终止进程，但不会生成core dump文件。
处理SIGTERM信号：
- 进程可以通过定义信号处理函数来响应SIGTERM信号，执行特定的清理代码后退出。
优雅关闭服务：
- 在许多Unix系统中，init在关闭电源前会向所有不重要的进程发送SIGTERM，等待几秒后，再发送SIGKILL以强制终止剩余进程。
编程中的SIGTERM处理：
- 在C/C++中，可以使用signal()或sigaction()函数来设置SIGTERM的信号处理函数，例如：signal(SIGTERM, handler_function);。
守护进程中的SIGTERM：
- 守护进程通常会捕获SIGTERM信号以优雅地关闭服务，执行必要的清理工作。

掌握这些关键点，你将能够理解SIGTERM信号的重要性以及如何在实际应用中处理它，确保进程能够优雅地终止并进行适当的资源清理。

Linux信号

SIGTERM
中文名一般叫“终止信号”，用于终止进程。
SIGTERM最常见的一个应用场景是，执行命令 kill ，该命令会终止进程号为PID的进程。注意，这里kill没有-9之类的额外参数。
进程捕捉到SIGTERM信号后，通常会做些善后工作然后退出，这个过程通常被叫做“优雅退出”。当然，进程也可以不做任何处理，忽略该信号，继续运行下去。信号可能被忽略了，这就是为啥有时候kill 根本不起作用。
除了kill命令，SIGTERM还有很多其他使用场景。比如，docker stop、supervisorctl stop背后的实现机制就是给进程发送SIGTERM信号。

SIGKILL
SIGKILL，名字明显比SIGTERM霸气，字面意思就是“杀死”进程。最常见的应用场景就是大名鼎鼎的kill -9 命令。
SIGKILL最大的特点是，被杀的进程根本无法捕获处理该信号，操作系统会负责直接杀掉进程，进程没有任何反抗的余地。这个大杀器效果立竿见影，但是也有副作用，就是经常来不及做任何善后工作，可能引起数据丢失等问题。比如说，一个进程可能会把接收到的数据先临时放到内存里，攒到若干MB后再一次性写入磁盘，从而避免频繁的磁盘IO操作（比如迅雷就是这么干的），如果进程被突然杀掉，那么它根本来不及把内存里的数据写入磁盘，进而导致这些数据丢失。

SIGINT
SIGINT的字面意思是“打断”，和SIGTERM类似，区别在于，该信号通常被用于前台进程（可以简单理解为可以在shell上长期存在，不会后台运行的程序）。
当我们使用命令行程序时，按下CTRL + C时，进程便会收到SIGINT信号。一般进程会捕获处理这个命令并退出。当然，跟处理SIGTERM信号一样，进程也可以选择忽略信号并继续运行。

systemd中环境变量的问题

在处理systemd服务中的环境变量问题时，以下是最重要的20%知识点，可以帮助你快速理解和解决大部分问题：

使用Environment指令设置环境变量：
在systemd的服务文件中，可以通过Environment指令直接设置环境变量。例如：
```
[Service]
Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
```
这样设置后，指定的变量将在服务启动时被设置。
使用EnvironmentFile导入环境变量文件：
如果你有多个环境变量需要设置，可以使用EnvironmentFile指令指向一个包含环境变量的文件。该文件中的每行格式为VarName=VarValue。例如：
```
[Service]
EnvironmentFile=/etc/test_env_service/var_file
```
其中/etc/test_env_service/var_file文件包含：
```
FILE_VAR1="Variable 1 from environment file"
FILE_VAR2="Variable 2 from environment file"
```
这样，文件中的变量将被导入到服务的环境中。
通过脚本来设置环境并启动服务：
另一种方法是编写一个包装脚本，在该脚本中设置所需的环境变量，然后启动服务。例如：
```
#!/bin/bash
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
exec /path/to/your/service
```
然后在systemd服务文件中引用这个脚本：
```
[Service]
ExecStart=/path/to/start-service.sh
```
这样，当systemd启动服务时，实际上是启动了这个脚本。
理解systemd服务中的环境变量限制：
systemd启动的服务通常不会加载用户的环境变量，尤其是/etc/profile下的环境变量。因此，你需要在服务文件中明确设置所需的环境变量。
使用systemctl edit进行配置覆盖：
为了避免修改原始的服务文件，可以使用systemctl edit <servicename>命令创建一个override文件，在其中设置环境变量。例如：
```
[Service]
Environment="Foo=bar"
```
这将在/etc/systemd/system/<servicename>.service.d/目录下创建一个override.conf文件，其中的设置将覆盖原始服务文件中的设置。