历史上，Linux操作系统一直采用 init进程 来启动整个系统。

sudo /etc/init.d/apache2 start

但是这种方法有两个缺点。

• 一是启动时间长。init进程是串行启动，只有前一个进程启动完，才会启动下一个进程。比如说先启动图形化系统，再启动网卡等等；

• 二是启动脚本复杂。init进程只是执行启动脚本，不管其他事情。脚本需要自己处理各种情况，这往往使得脚本变得很长。

1. Systemd的概述

Systemd 就是为了解决这些问题而诞生的。它的设计目标是，为系统的启动和管理提供一套完整的解决方案。

根据 Linux 惯例，字母d是守护进程（daemon）的缩写。 Systemd 这个名字的含义，就是它要守护整个系统。它不仅负责启动操作系统，还负责僵尸进程的回收和服务挂掉后的自动重启。

使用了 Systemd，就不需要再用init了。Systemd 取代了initd，成为系统的第一个进程（PID 等于 1），其他进程都是它的子进程。

ps -p 1 #查看PID为1的进程，可以看到就是systemd

Systemd 的优点是功能强大，使用方便，缺点是体系庞大，非常复杂。现在还有很多人反对使用 Systemd，理由就是它过于复杂，与操作系统的其他部分强耦合，违反"keep simple, keep stupid"的Unix 哲学。

但是你能想象，重启 sshd, networking 不用 Systemctl 来实现，而是每一个模块用一个不同的命令吗？那才是真的要了老命。

2. 可执行文件和Service

Service的位置放在 /lib/systemd/system路径下 , 只有这里的Service才能被systemd使用

以一个已经启动了的nginx进程为例，当某网页返回错误404的时候，排查的步骤中就会包括服务器端查看后台的Nginx是否还正常

systemctl status nginx.service

查看一下是不是Nginx挂掉了，导致前端打不开了。这里引出的具体论点就是:

• 实际工作的是二进制文件 Nginx
• Nginx.service实际上是一本说明书，说明了该如何控制 Nginx 这个二进制文件
• 而Systemd就是参考Nginx. Service这个说明书，来对实际的进程(运行中的二进制文件)进行操作的,比如说服务挂了要不要重启，生成的日志要打印到哪个目录下，加载的配置是在哪个路径

2.1 一个典型的Service是啥样的

[Unit]
Description=我的自定义APP  # 它是谁
After=network.target      # 它要在网络启动后才启动（逻辑顺序）

[Service]
ExecStart=/usr/bin/python3 /app/main.py  # 怎么启动（二进制程序路径）
Restart=always                           # 挂了怎么办（自动重启）

[Install]
WantedBy=multi-user.target  # 开机自启时属于哪个级别

2.2 Systemctl的实际工作流

比如当用户执行 systemctl start nginx 的时候，实际发生的事情是这样的:

• 查找： systemctl 通知 Systemd 寻找名为 nginx.service 的文件
• 解析： Systemd 读取说明书里的 ExecStart=/usr/sbin/nginx, 找到对应的二进制文件
• 执行： Systemd 创建一个环境，把二进制程序跑起来。
• 记录： 程序启动时打印的“Starting Nginx...”等信息，被 journald 守护进程接管。
• 反馈： 这就是为什么可以通过 journalctl -u nginx 来查看程序执行的时候到底发生了什么

3. Systemd 服务排查与管理心得

一、常用的服务查看与管理命令

1. 列出当前已加载的服务

查看系统中所有已加载的(Service)服务单元（包括是否运行、是否失败等）：

systemctl list-units --type=service

2. 查看单个服务的详细状态

systemctl status nginx

3. 启动、停止、重启与设置开机自启

systemctl start <service>
systemctl stop <service>
systemctl restart <service>
systemctl enable <service>    # 设置开机自启
systemctl disable <service>   # 取消开机自启

4. 查看服务对应的 unit 文件

systemctl cat <service>

或直接查看物理路径：

/usr/lib/systemd/system/<service>.service

---

5. Journalctl的常用命令

在debian最新的操作系统里面，已经取消了/var/log/syslog文件，所有的service的log和系统内核的log都集中使用journalctl进行查看了

以下是我日常工作中经常使用的命令，老实说journalctl查对应时间点的语法使用起来真的是太不够简洁了。

1. 查看 某一个服务 最近 1 小时的日志

journalctl -u nginx --since "1 hour ago"

2. 查看特定日期范围的日志

journalctl -u nginx --since "2024-05-01" --until "2024-05-02 03:00"

3. 实时查看最新的报错 -f (follow)：实时滚动显示新产生的日志（类似 tail -f）

journalctl -u nginx -f

4. 查看对应的系统内核日志(-k)

journalctl -k | tail -n 50

5. 查看本次启动的日志

journalctl -b 1 -n 100

• -b -1: 查看上一次启动周期的日志。
  • -b 0 指的是本次启动;
  • -b -1是上一次， -b -2 以此类推，还是比较简洁明了的
• -n 100: 只显示该周期的最后100行日志，对于"宕机"的设备而言，刚好可以体现系统宕机前最后的报错

6. 排查硬件问题导致的异常宕机、重启

# 过滤内存、硬件和重启相关信息
sudo journalctl -k -b -1 --no-pager | grep -Ei 'hardware error|mce|edac|ecc|memory|dimm|panic|oops|watchdog|reboot|reset'

sudo journalctl -b -1 --no-pager | grep -Ei 'shutdown|power|reboot|signal 15|stopping system'