[TOC]
0x00 Systemd 简述
描述:系统启动和服务器守护进程管理器，负责在系统启动或运行时激活系统资源，并且管理服务器进程和其它进程，可以说他是Linux的小伙伴系统启动时候最先都是运行的systemd;1
2
3$ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 128204 5884 ? Ss 3月25 2:19 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
1.Linux 启动流程
描述:要想清楚 systemd 在 Linux 系统中的地位和作用，就不得不提一下 Linux 的启动流程；
Linux 从按下电源键到进入用户交互界面整个启动流程大致可以分为四个阶段：
- BIOS 阶段: 基本的硬件自检准备以及加载 bootloader 程序;
- BootLoader 阶段
- kernel 加载阶段
- init (
systemd/sysvinit 初始化阶段)
(1) BIOS 阶段
Step 1.在按下电源电源键（冷启动）后，CPU 的程序计数器被初始化为一个特定的內存地址(所以没有 CPU 是无法启动主板上的 BIOS 的)，存储在只读存储器（ROM）中的 BIOS 就是从这个特定的內存地址开始执行，值得注意的是对于嵌入式系统中的 CPU ，将会加载引导区去启动 flash/ROM 中已知地址的程序；
Step2.BIOS 启动后就开始执行硬件的基本初始化也称之为上电自检,并根据引导设备的优先级将系统控制权交给硬件启动项（比如硬盘/网络/U盘等）,此阶段可以进行外部中断我们按下 F12 或者 ESC 键（根据主板芯片组而异）就会弹出选择启动项的界面，而且这些按键高度依赖硬件。
Step3.BIOS 选择好硬件启动项之后就开始执行硬件设备上的初级引导程序代码，对于 MBR 硬盘来讲是最开始的一个扇区（512字节）將被加载到內存，並执行行其中的初始化代码来加载下一阶段的 Bootloader
PS:此处以MBR引导的系统记录为例，MBR 主引导记录是一个 512 字节的扇区，位于硬盘的第一扇区（0道0柱1扇区），对于 GPT/EFI 引导等有经验的时候再来讲解补充;1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16#dd 命令读取 MBR 主引导记录
dd if=/dev/sda of=mbr.bin bs=512 count=1
#od 命令来查看二进制文件
od -xa mbr.bin
# 0000000 63eb 0090 0000 0000 0000 0000 0000 0000
# k c dle nul nul nul nul nul nul nul nul nul nul nul nul nul
# 0000020 0000 0000 0000 0000 0000 0000 0000 0000
# nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
# *
# 0000120 0000 0000 0000 0000 0000 8000 0800 0000
# nul nul nul nul nul nul nul nul nul nul nul nul nul bs nul nul
# 0000140 0000 0000 faff 9090 c2f6 7480 f605 70c2
# nul nul nul nul del z dle dle v B nul t enq v B p
# 0000160 0274 80b2 79ea 007c 3100 8ec0 8ed8 bcd0
# t stx 2 nul j y | nul nul 1 @ so X so P <
(2) BootLoader 阶段
主引导记录加载完 Bootloader（主要为GRUB）到 RAM 中之后，GRUB 会根据需求显示一个可用的内核列表（定义在/etc/grub.conf，/etc/grub/menu.lst和/etc/grub.conf的软连接）
根据 GRUB 的配置加载默认内核镜像和 initrd 镜像到内存中，当所有镜像准备好后，即跳转到内核镜像（针对于Windows可能有些许不同但都大同小异）。
(3) kernel 阶段
当BootLoader 阶段完成之后内核镜像(kernel image)被加载到内存中，系统的控制权就交给内核镜像由此内核阶段开始了;
内核镜像不是一个可以执行的内核，而是一个被压缩的内核镜像 （zImage 或 bzImage）, 在内核镜像的头部有一个小型程序 routine 其做少量的硬件设置 ，然后自解压压缩的内核镜像并放到高端内存。
如果存在初始磁盘镜像（initrd）, routine 将拷贝 initrd 以供稍后安装使用，然后 routine 将调用内核开始内核启动。
在内核引导过程中，初始 RAM 磁盘（initrd）是由 BootLoader 加载到内存中的，它会被复制到 RAM 中并挂载到系统上。
initrd 作为 RAM 中的临时根文件系统使用，并允许内核在没有挂载任何物理磁盘的情况下完整地实现引导(实际上CentOS7忘记使用进行恢复也是主要依赖于initrd),由于与外围设备进行交互所需要的模块可是 initrd 的一部分，因此内核可以非常小，但是仍然支持大量可能的硬件配置
在内核启动后就可以正式装备根文件系统了（通过 pivot_root），此时会将 initrd 根文件系统卸载掉并挂载真正的根文件系统。
initrd 函数可以创建一个小型的 Linux 内核，其中包括作为可加载模块编译的驱动程序, 并且该模块可以为内核提供了访问磁盘和磁盘上的文件系统的方法，并为其他硬件提供了驱动程序
由于根文件系统是磁盘上的一个文件系统，因此 initrd 函数会提供一种启动方法来获得对磁盘的访问，并挂载真正的根文件系统。但是在没有硬盘的嵌入式目标中，initrd 可以是最终的根文件系统，或者也可以通过网络文件系统（NFS）来挂载最终的根文件系统。
1 | #使用 dmesg 来查看从加载内核后的流程 |
（4）init 阶段
当内核自解压完成启动并初始化后，内核启动第一个用户空间应用程序即 systemd 进程（其实是老式 System V 系统的 init 程序的替代品)并将控制权移交给它; 这是系统启动后调用的第一个使用标准 C 库编译的程序，在此进程之前还没有执行任何标准的 C 应用程序，至此整个系统引导过程的结束；
此时 kernel和 systemd 处于工作运行状态然后就由systemd来管理各项程序，有可能您从dmesg输错的日志上该阶段首先执行/sbin/init命令而对于采用systemd的发行版来说，实际上/sbin/init 是指向 /lib/systemd/systemd的软链接文件;1
2[ 2.516258] Run /sbin/init as init process
[ 3.992535] systemd[1]: systemd 237 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
2.主角登场
Q:为什么为systemd是 Linux 的小伙伴?
答:其实广义上来讲 Linux 是众多 Linux 系统发行版的集合，但严格来讲 Linux 仅仅是一个 OS 的 kernel 而已，仅仅有一个内核是无法组成一个系统的，所以 Linux kernel 还需要他的几个兄弟比如 GNU 、 systemd 、X Window 、GNOME 、 KDE 、Xfce 等等其他用户层面的程序来构建出一套完整的操作系统出来
比如: GNU/Linux 将 Debian 哲学与方法论，GNU 工具集、Linux 内核，以及其他重要的自由软件结合在一起所构成的独特的软件发行版称为 Debian GNU/Linux。
systemd 简介
描述:在片头的时候我大致对systemd的工作做了一个总结，在本章节我对其深入的讲解
systemd 是一个 Linux 系统基础组件的集合，提供了一个系统和服务管理器，运行为 PID 1 并负责启动其它程序。
功能包括：
- 支持并行化任务；
- 同时采用 socket 式与 D-Bus 总线式激活服务；
- 按需启动守护进程（daemon）；
- 利用 Linux 的 cgroups 监视进程；
比如systemctl 显示 CPU 和 Mem 信息就是基于此哦。 - 支持快照和系统恢复；
- 维护挂载点和自动挂载点；
- 各服务间基于依赖关系进行精密控制。
- systemd* 支持 SysV 和 LSB 初始脚本，可以替代 sysvinit。
- 除此之外功能还包括日志进程、控制基础系统配置，维护登陆用户列表以及系统账户、运行时目录和设置，可以运行容器和虚拟机，可以简单的管理网络配置、网络时间同步、日志转发和名称解析等。
systemd 设计目标
描述:在Redhat、CentOS等系列发行版中从7.x ~ 8.x 正式采用systemd作为系统服务管理工具的内核系统服务;它融合之前service和chkconfig的功能于一体,所以说它也能在 /etc/init.d/ 启动脚本进行扫描查看相程序;
主要目标：
- 改进效能：使用二进制代码替换松散的SYSV启动脚本，减少频繁的进程创建/ 库加载/ 内核/用户切换；
- 启动并行化: 利用 Dbus 进程间通讯与 socket 激活机制，解决任务启动时的依赖问题
- 实现任务（daemons）精确控制：使用内核的 cgroup 机制，不依赖 pid 来追踪进程，即使是两次 fork之后生成的守护进程也不会脱离 systemd 的控制
- 统一任务定义: 用户不需要自行编写 shell 脚本，而仅依据 systemd 制定的 unit 规则；
systemd 体系架构
systemd体系架构如下:
- 1.最底层：
systemd 内核层面依赖 cgroup、autofs、kdbus - 2.第二层：
systemd libraries是 systemd 依赖库 - 3.第三层：
systemd Core是 systemd 自己的库 - 4.第四层：
systemd daemons以及 targets 是自带的一些基本 unit、target，类似于 sysvinit 中自带的脚本 - 5.最上层就是和 systemd 交互的一些工具，比如我们下面将要学习的systemctl;
WeiyiGeek.systemd体系
Linux 整体硬件与systemd体系架构： WeiyiGeek.Linux硬件
0x01 Systemd Unit
描述：systemd核心概念unit（单元）类型：unit表示不同类型的systemd对象，并提供了处理不同单元之间依赖关系的能力,通过配置文件进行标识和配置；
Systemd 服务编写参考: http://www.jinbuguo.com/systemd/systemd.service.html
文件中主要包含了系统服务、监听socket、保存的系统快照以及其它与init相关的信息;
| type | name | 作用 |
|---|---|---|
| Service unit | .service | 用于封装一个后台服务进程 |
| Target unit | .target | 用于将多个单元在逻辑上组合在一起。 |
| Device unit | .device | 用于定义内核识别的设备，在 sysfs(5) 里面作为 udev(7) 设备树展示 |
| Socket unit | .socket | 用于标识进程间通信用到的socket文件 |
| Snapshot unit | .snapshot | 管理系统快照 |
| Swap unit | .swap | 用于标识swap 文件或设备 |
| Mount unit | .mount | 用于封装一个文件系统挂载点(也向后兼容传统的 /etc/fstab 文件) |
| Automount unit | .automount | 用于封装一个文件系统自动挂载点 |
| Path unit | .path | 用于根据文件系统上特定对象的变化来启动其他服务。 |
| Time unit | .timer | 用于封装一个基于时间触发的动作。取代传统的 crond 等任务计划服务 |
| Slice unit | *.slice | 用于控制特定 CGroup 内所有进程的总体资源占用。 |
systemd 只在内存中加载最小化的一组单元 只有至少满足下列条件之一的单元，才会被加载到内存中：
1.处于 活动(active)、启动中(activating)、停止中(deactivating)、失败(failed) 状态之一(也就是停止(inactive)之外的状态)
2.至少有一个作业正在作业队列中
3.至少有一个其他已经加载到内存中的单元依赖于它
4.仍然占有某些资源 (例如一个已停止的服务单元的进程忽略了终止请求，仍在逗留)
5.被 D-Bus 调用以程序化的方式固定到了内存中
实际上用户并不能显而易见的看到某个单元是否已被加载到内存用 systemctl list-units –all 命令可以显示当前已加载到内存中的所有单元不满足加载条件(见上文)的单元会被立即从内存中卸载，并且它的记帐数据(accounting data)也会被清空。 不过因为每当一个单元关闭时，都会生成一条日志记录声明该单元所消耗的资源， 所以这些数据通常不会彻底消失。
1.配置文件
在 CentOS/RedHat 发行版中
man systemd.unit1
2
3
4
5
6
7
8
9
10Table 1. Load path when running in system mode (--system).
┌────────────────────────┬─────────────────────────────┐
│Path │ Description │
├────────────────────────┼─────────────────────────────┤
│/etc/systemd/system │ Local configuration │
├────────────────────────┼─────────────────────────────┤
│/run/systemd/system │ Runtime units │
├────────────────────────┼─────────────────────────────┤
│/usr/lib/systemd/system │ Units of installed packages │
└────────────────────────┴─────────────────────────────┘
在 Ubuntu/Debian 发行版中
man systemd.unit1
2
3
4
5
6
7
8
9
10Table 1. Load path when running in system mode (--system).
┌────────────────────┬─────────────────────────────┐
│Path │ Description │
├────────────────────┼─────────────────────────────┤
│/etc/systemd/system │ Local configuration │
├────────────────────┼─────────────────────────────┤
│/run/systemd/system │ Runtime units │
├────────────────────┼─────────────────────────────┤
│/lib/systemd/system │ Units of installed packages │
└────────────────────┴─────────────────────────────┘
在使用 yum/apt 或其他包管理器，以及 rpm/deb 等软件包安装软件的时候，如果该软件支持 systemd 管理的话，就会自动在/usr/lib/systemd/system目录添加一个配置文件(针对于CentOS说明)，此时可以采用systemctl cat name 来查看该软件的 systemd 单元文件
但是如果软件没有自带 systemd 配置文件的话，我们可以自己搓一个配置文件出来，并复制到相应的目录下即可（后续我会简单配置一个实例[Webp Server Go](https://github.com/webp-sh/webp_server_go)）
service unit文件格式说明（类似于windows下的ini）：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39man systemd.service #参考
[unit]
Description：描述信息
After：定义unit的启动次序，表示当前unit应该晚于哪些unit启动，其功能与Before相反
Requires：依赖到的其它units，强依赖，被依赖的units无法激活时，当前unit也无法激活
Wants：依赖到的其它units，弱依赖
Conflicts：定义units间的冲突关系
[Service] #与特定类型相关的专用选项；此处为Service类型
Type：定义影响ExecStart及相关参数的功能的unit进程启动类型
simple：默认值，这个daemon主要由ExecStart接的指令串来启动，启动后常驻于内存中
forking：由ExecStart启动的程序透过spawns延伸出其他子程序来作为此daemon的主要服务。原生父程序在启动结束后就会终止
oneshot：与simple类似，不过这个程序在工作完毕后就结束了，不会常驻在内存中
dbus：与simple类似，但这个daemon必须要在取得一个D-Bus的名称后，才会继续运作.因此通常也要同时设定BusNname=才行
notify：在启动完成后会发送一个通知消息。还需要配合 NotifyAccess 来让 Systemd 接收消息
idle：与simple类似，要执行这个daemon必须要所有的工作都顺利执行完毕后才会执行。这类的daemon通常是开机到最后才执行即可的服务
EnvironmentFile=/etc/sysconfig/sshd #环境file
ExecStart=/usr/sbin/sshd -D $OPTIONS #启动
ExecReload=/bin/kill -HUP $MAINPID #重启
KillMode=process #关闭
Restart=on-failure # Restart: fail 时重启
RestartSec=42s
[Target]
#.target定义了一些基础的组件，供.service文件调用
[Mount]
#.mount文件定义了一个挂载点，[Mount]节点里配置了What,Where,Type三个数据项
#等同于以下命令：mount -t hugetlbfs /dev/hugepages hugetlbfs
What=hugetlbfs
Where-/dev/hugepages
Type=hugetlbfs
[Install]：#定义由“systemctl enable”以及"systemctl disable“命令在实现服务启用或禁用时用到的一些选项
Alias：别名，可使用systemctl command Alias.service
RequiredBy：被哪些units所依赖，强依赖
WantedBy：被哪些units所依赖，弱依赖 多用户模式下需要的
Also：安装本服务的时候还要安装别的相关服务
注意事项:
- 不同的发行版 systemd unit 的 path 不一样，但是总体来说systemd 的配置文件主要位于以下三个目录中
/usr/lib/systemd/system或/lib/systemd: 使用包管理器安装的软件的 systemd unit 件实际配置文件的存放位置/run/systemd/system：在运行时创建的s ystemd unit 文件。该目录优先于已安装服务单元文件的目录。/etc/systemd/system:优先级最高，由 systemctl 命令创建的 systemd unit 文件以及为扩展服务而添加的 unit 文件都将启用。
2.启动流程
当内核加载到内存中后开始执行 systemd，并且根据 dmesg 的日志我们可以了解到 systemd 启动后执行了哪一些操作
1 | [ 2.516258] Run /sbin/init as init process |
下面的图表解释了 这些具有特定含义的 target 单元之间的依赖关系 以及各自在启动流程中的位置。图中的箭头表示了单元之间的依赖关系与先后顺序， 整个图表按照自上而下的时间顺序执行。
1 | local-fs-pre.target |
(1) systemd 执行的第一个目标是 default.target。但实际上 default.target 是指向 graphical.target 的软链接。Graphical.target 的实际位置是/usr/lib/systemd/system/graphical.target
1 | $ cat /usr/lib/systemd/system/graphical.target |
(2) 在default.target这个阶段，会启动multi-user.target而这个 target 将自己的子单元放在目录/etc/systemd/system/multi-user.target.wants里。这个 target 为多用户支持设定系统环境。非 root用户会在这个阶段的引导过程中启用。防火墙相关的服务也会在这个阶段启动。multi-user.target会将控制权交给另一层basic.target。
1 | cat /usr/lib/systemd/system/multi-user.target |
（3）basic.target单元用于启动普通服务特别是图形管理服务。它通过/etc/systemd/system/basic.target.wants目录来决定哪些服务会被启动，basic.target 之后将控制权交给 sysinit.target.
1 | $ tree /etc/systemd/system/multi-user.target.wants |
(4) sysinit.target会启动重要的系统服务例如系统挂载，内存交换空间和设备，内核补充选项等等。sysinit.target 在启动过程中会传递给local-fs.target。
1 | tree /etc/systemd/system/basic.target.wants |
(5) local-fs.target，这个 target 单元不会启动用户相关的服务，它只处理底层核心服务。这个 target 会根据 /etc/fstab 和 /etc/inittab 来执行相关操作。
1 | cat /usr/lib/systemd/system/sysinit.target |
3.进程树(Process tree)
使用 pstree 命令来看一哈进程树的状态，用户空间的进程都挂在 PID 为 1 的 systemd 下，注意该命令不是发行版本内置的需要进行安装 yum install pstree;
1 | ╭─[email protected] ~ |
4.运行级别
描述: 如今systemd 引入了一个和启动级别(一个旧的概念)功能相似又不同的概念——目标（target）。不像数字表示的启动级别，每一个目标都有名字和独特的功能，而且能同一时候启用多个，一些目标继承其它目标的服务，并启动新服务。
| SysV 启动级别 | Systemd 目标 | 描述 |
|---|---|---|
| 0 | runlevel0.target, poweroff.target | 中断系统（halt） |
| 1, s, single | runlevel1.target, rescue.target | 单用户模式 |
| 2, 4 | runlevel2.target, runlevel4.target, multi-user.target | 用户自己定义启动级别。通常识别为级别3。 |
| 3 | runlevel3.target, multi-user.target | 多用户，无图形界面。用户能够通过终端或网络登录。 |
| 5 | runlevel5.target, graphical.target | 多用户。图形界面。继承级别3的服务。并启动图形界面服务。 |
| 6 | runlevel6.target, reboot.target | 重新启动 |
| emergency | emergency.target | 急救模式（Emergency shell） |
0x02 Systemd Manager
控制 systemd 的主要命令主要有以下几种：
- systemctl 命令控制
systemd的管理系统和服务的命令行工具 - systemsdm 命令控制
systemd的管理和服务的图形化工具 - journalctl 命令查询
systemd日志系统 - loginctl 命令控制
systemd登入管理器 - systemd-analyze 分析系统启动效能（类似开机时间)
1.Systemctl 命令
描述:systemctl help <单元> ## 显示单元的手冊页（必须由单元文件提供）：1
2
3
4
5
6
7
8
9
10#unit类型或者单元：
service ：文件扩展名为.service, 用于定义系统服务
target ：文件扩展名为.target，用于模拟实现运行级别
device ：用于定义内核识别的设备
mount：定义文件系统挂载点
socket：用于标识进程间通信用的socket文件，也可在系统启动时，延迟启动服务，实现按需启动
snapshot ：管理系统快照
swap：用于标识swap设备
automount ：文件系统的自动挂载点
path：用于定义文件系统中的一个文件或目录使用,常用于当文件系统变化时，延迟激活服务
Systemctl 新特性:
- 系统引导时实现服务并行启动
- 按需启动守护进程
- 自动化的服务依赖关系管理
- 同时采用socket式与D-Bus总线式激活服务
- 系统状态快照
优先级从低到高各自是：
- /usr/lib/systemd/system/: 软件包安装的单元 #(Centos)
Ubuntu：/lib/systemd/system - /etc/systemd/system/: 系统管理员安装的单元
- /etc/init.d/ ：软件安装服务单元（#任然有部分软件采用和用户自定义脚本）
- 当systemd执行在用户模式下时，使用的载入路径是全然不同的;systemd 单元名仅能包括 ASCII 字符, 下划线和点号. 其它字符须要用 C-style “\x2d” 替换. 參阅 man systemd.unit 和 man systemd-escape.}}
参数语法1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69#0.启动/重启/停止/重载服务
systemctl start NAME
systemctl restart NAME
systemctl stop NAME
systemctl reload NAME
#1.查看服务状态
systemctl status NAME
#2.重启守护程序-修改过服务单元配置文件必须执行它（扫描新的或有变动的单元）
systemctl daemon-reload
#3.可以实现对其他机器的远程控制，该功能使用 SSH 连接。
systemctl 参数中添加 -H <用户名>@<主机名>
#4.杀死服务
systemctl kill NAME
#5.Systemctl配置查看
systemctl show
# Version=219
# Features=+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN
# Virtualization=vmware
# Architecture=x86-64
# FirmwareTimestampMonotonic=0
# LogLevel=info
# LogTarget=journal-or-kmsg
# NNames=259
# NFailedUnits=1
# NJobs=0
# NInstalledJobs=64971823
# NFailedJobs=65792
# Progress=1
# Environment=LANG=zh_CN.UTF-8 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
# ConfirmSpawn=no
# ShowStatus=no
# UnitPath=/etc/systemd/system /run/systemd/system /run/systemd/generator /usr/local/lib/systemd/system /usr/lib/systemd/system /run/systemd/generator.late
# DefaultStandardOutput=journal
# DefaultStandardError=journal
# RuntimeWatchdogUSec=0
# ShutdownWatchdogUSec=10min
# SystemState=degraded
# DefaultTimerAccuracyUSec=1min
# DefaultTimeoutStartUSec=1min 30s
# DefaultTimeoutStopUSec=1min 30s
# DefaultRestartUSec=100ms
# DefaultStartLimitInterval=10000000
# DefaultStartLimitBurst=5
# DefaultCPUAccounting=yes
# DefaultBlockIOAccounting=no
# DefaultMemoryAccounting=yes
# DefaultTasksAccounting=yes
# DefaultLimitCPU=18446744073709551615
# DefaultLimitFSIZE=18446744073709551615
# DefaultLimitDATA=18446744073709551615
# DefaultLimitSTACK=18446744073709551615
# DefaultLimitCORE=18446744073709551615
# DefaultLimitRSS=18446744073709551615
# DefaultLimitNOFILE=4096
# DefaultLimitAS=18446744073709551615
# DefaultLimitNPROC=14991
# DefaultLimitMEMLOCK=65536
# DefaultLimitLOCKS=18446744073709551615
# DefaultLimitSIGPENDING=14991
# DefaultLimitMSGQUEUE=819200
# DefaultLimitNICE=0
# DefaultLimitRTPRIO=0
# DefaultLimitRTTIME=18446744073709551615
# DefaultTasksMax=18446744073709551615
基本用法
1 | #示例0.自启与启动等常用命令 |
2.Journal 命令
描述：作为最具吸引力的优势，systemd拥有强大的处理与系统日志记录功能。在使用其它工具时，日志往往被分散在整套系统当中，由不同的守护进程及进程负责处理，这意味着我们很难跨越多种应用程序对其内容进行解读。
systemd 的第二个主要部分是 journal 日志系统，类似于 syslog 但也有些显著区别。
Tips : 如果你喜欢用 sed 、grep 、awk 三剑客来处理日志，那么当你面对 journal 日志系统的时候你就准备掀桌儿吧！因为这是个二进制日志，无法使用常规的命令行文本处理工具来解析它
Systemd Journal 的优点如下：
- 简单性：代码少，依赖少，抽象开销最小。
- 零维护：日志是除错和监控系统的核心功能，因此它自己不能再产生问题。举例说，自动管理磁盘空间，避免由于日志的不断产生而将磁盘空间耗尽。
- 移植性：日志 文件应该在所有类型的 Linux 系统上可用，无论它使用的何种 CPU 或者字节序。
- 性能：添加和浏览 日志 非常快。
- 最小资源占用：日志 数据文件需要较小。
- 统一化：各种不同的日志存储技术应该统一起来，将所有的可记录事件保存在同一个数据存储中。所以日志内容的全局上下文都会被保存并且可供日后查询。例如一条固件记录后通常会跟随一条内核记录，最终还会有一条用户态记录。重要的是当保存到硬盘上时这三者之间的关系不会丢失。Syslog 将不同的信息保存到不同的文件中，分析的时候很难确定哪些条目是相关的。
- 扩展性：日志的适用范围很广，从嵌入式设备到超级计算机集群都可以满足需求。
- 安全性：日志 文件是可以验证的，让无法检测的修改不再可能。
日志的优先级和分类
系统日记按(优先级Priority level)和(设施Facility)对信息进行分类。日志分类对应于经典的Syslog协议（RFC 5424）。
注：下面表格最后一列 (wc -l) 是统计的记录数比例，总数是3个月的日志，大约100万条数据。
（1）优先级： WeiyiGeek.
（2）设施分类：
WeiyiGeek.
journalctl 命令帮助
1 | journalctl -h |
实际案例:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123#实例1.显示bootloader启动信息
$ sudo journalctl -b #启动信息23565
$ sudo journalctl -b -0
$ sudo journalctl -b -1 #前一次启动信息... 通过查询引导列表可看到最多能查看前几次启动信息
$ sudo journalctl --list-boots #引导列表
#实例2.显示不早于指定日期的条目何特定区间的数据(利用--since与--until选项设定时间段)。
$ sudo journalctl --since="2019-06-13 16:42:34"
$ sudo journalctl --since "20 min ago" #Show all messages since 20 minutes ago: 最近20分钟
$ sudo journalctl -S "20 min ago"
$ journalctl --since "2015-01-10" --until "2015-01-11 03:00"
$ journalctl --since 09:00 --until "1 hour ago" # 获得早9：00到一小时前这段时间内的报告
#实例3.持续显示最新新消息默认10条
$ sudo journalctl -f
#实例4.显示特定可执行文件的信息(按组件路径)
$ sudo journalctl /usr/lib/systemd/systemd
#实例5.显示特定进程PID的日志信息，以及用户或者群组ID
$ sudo journalctl _PID=1
$ sudo journalctl _UID=33 --since today
$ sudo journalctl -F _GID # 查看systemd journal拥有条目的群组ID
#实例6.显示特定单元日志信息
$ sudo journalctl -u man-db.service
journalctl -u nginx.service -u php-fpm.service --since today
#实例7.显示当前引导的内核消息日志(--dmesg)
$ sudo journalctl -k
$ sudo journalctl -k -b -5 # 查询五次之前引导环境的信息
#实例8.-p 显示具有指定优先级的条目(0-7)
# 0: emerg
# 1: alert
# 2: crit
# 3: err
# 4: warning
# 5: notice
# 6: info
# 7: debug
# 以上为可在-p选项中使用的数字或者名称。
$ sudo journalctl -p err..alert
$ sudo journalctl -p 3..1 //3-1
$ sudo journalctl -p 3 //3-0
$ sudo journalctl -p 3 -r //3-0; 加-r选项,首先显示最新的条目
#实例9.通过在syslog工具上进行过滤来显示等效的auth.log(内核相关信息)
$ sudo journalctl SYSLOG_FACILITY=10
# 0 kern 内核；
# 1 user 用户；
# 3 daemon 守护进程；
# 4 auth 授权；
# 10 authpriv 授权；
$ sudo journalctl SYSLOG_FACILITY=0 -r
$ sudo journalctl -k -r
$ sudo journalctl SYSLOG_FACILITY=4 |wc -l
#14516
$ sudo journalctl SYSLOG_FACILITY=10 |wc -l
#9049
#实例10.如果日志目录(默认位于/var/log/journal下)包含大量日志数据，那么journalctl可能需要几分钟来过滤输出。
#它可以通过使用——file选项来强制journalctl只查看最近的日志，从而显著加快速度:
$ sudo journalctl --file /var/log/journal/*/system.journal -f
#实例11.手动清理日志文件删除已归档的日志文件
$ sudo journalctl --vacuum-size=100M #直到它们使用的磁盘空间低于100M：
$ sudo journalctl --vacuum-time=2weeks #使所有日记文件不包含超过2周的数据。
#实例12.查看 kubelet 服务的相关日志
journalctl -xeu kubelet
# 示例13.以UTC显示时间戳
journalctl --utc
# 示例14.查看Journald中已经记录的引导信息
journalctl --list-boots
-1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC
# 例如，要查看上次引导的journal记录，则可使用-1相对指针配合-b标记： journalctl -b -1
# journalctl -b caf0524a1d394ce0bdbcff75b94444fe
# 示例15.截断或者扩大输出结果，在默认情况下journalctl会在pager内显示各条目，并通过右箭头键访问其信息
journalctl --no-full
# 示例16.本操作工具对数据进行处理则可能需要使用标准格式
journalclt --no-pager # 标准输出结果
# 示例17.输出格式(特定)
# cat: 只显示信息字段本身。
# export: 适合传输或备份的二进制格式。
# json: 标准JSON，每行一个条目。
# json-pretty: JSON格式，适合人类阅读习惯。
# json-sse: JSON格式，经过打包以兼容server-sent事件。
# short: 默认syslog类输出格式。
# short-iso: 默认格式，强调显示ISO 8601挂钟时间戳。
# short-monotonic: 默认格式，提供普通时间戳。
# short-precise: 默认格式，提供微秒级精度。
# verbose: 显示该条目的全部可用journal字段，包括通常被内部隐藏的字段。
# 上述选项允许大家以最适合需求的格式显示journal条目。
journalctl -b -u nginx -o json
journalctl -b -u nginx -o json-pretty
# 示例17.查看近期日志指定条数。
journalctl -n 20 # 同样为tail -n 20
journalctl -f # 同样为tail -f
# 示例18.Journal维护清理部分陈旧日志以释放存储空间。
journalctl --disk-usage
# Journals take up 8.0M on disk.
# –vacuum-size选项: 其会不断删除旧有记录直到所占容量符合要求
sudo journalctl --vacuum-size=1G
# –vacuum-time选项：任何早于这一时间点的条目都将被删除 (去年之后的条目才能保留)
sudo journalctl --vacuum-time=1years
# 重启
systemctl restart journald
配置文件设置:
(1) 日志大小限制设置
默认为基础文件系统的10%，但上限为4GB。
例如本机/var/log/journal/位于30Gb分区上，日志最多需要3Gb。超过40Gb的分区，日志文件需要最大值都为4Gb。
可以通过取消注释和更改以下内容来控制持久日志的最大大小：1
2
3
4
5
6
7$vim /etc/systemd/journald.conf
SystemMaxUse=50M
#也可以使用drop-in snippets配置覆盖机制，而不是编辑全局配置文件。在这种情况下，将覆盖置于[Journal]标题下：
$vim /etc/systemd/journald.conf.d/00-journal-size.conf
[Journal]
SystemMaxUse=50M
修改后重新启动日志系统 systemd-journald.service 即 systemctl restart systemd-journald.service;
(2) 过往引导记录持久化1
2
3
4
5
6# 方式1.当Storage=auto选项时创建以下目录进行日志的持久化。
sudo mkdir -p /var/log/journal
# 方式2:在[Journal]区段下将Storage=选项设定为“persistent”以启用持久记录：
vim /etc/systemd/journald.conf
Storage=persistent
(3) 限定Journal扩展
大家可以配置自己的服务器以限定journal所能占用的最高容量。要实现这一点，我们需要编辑/etc/systemd/journald.conf文件。1
2
3
4
5
6
7
8
9
10以下条目可用于限定journal体积的膨胀速度：
SystemMaxUse=: 指定journal所能使用的最高持久存储容量。
SystemKeepFree=: 指定journal在添加新条目时需要保留的剩余空间。
SystemMaxFileSize=: 控制单一journal文件大小，符合要求方可被转为持久存储。
RuntimeMaxUse=: 指定易失性存储中的最大可用磁盘容量（/run文件系统之内）。
RuntimeKeepFree=: 指定向易失性存储内写入数据时为其它应用保留的空间量（/run文件系统之内）。
RuntimeMaxFileSize=: 指定单一journal文件可占用的最大易失性存储容量（/run文件系统之内）。
通过设置上述值，大家可以控制journald对服务器空间的消耗及保留方式。
(4) journald日志被打满设置1
2
3vim /etc/systemd/journald.conf
RateLimitInterval=30s
RateLimitBurst=100000
Tips : JSON(JavaScript Object Notation)是一种轻量级的数据交换格式。易于人阅读和编写。同时也易于机器解析和生成。它基于JavaScriptProgramming Language, Standard ECMA-262 3rd Edition - December 1999的一个子集。JSON采用完全独立于语言的文本格式，但是也使用了类似于C语言家族的习惯（包括C, C++, C#, Java,JavaScript, Perl, Python等）。这些特性使JSON成为理想的数据交换语言。
JSON建构于两种结构：
- “名称/值”对的集合（A collection ofname/value pairs）：不同的语言中，它被理解为对象（object），纪录（record），结构（struct），字典（dictionary），哈希表（hash table），有键列表（keyed list），或者关联数组（associativearray）。
- 值的有序列表（An ordered list of values）：在大部分语言中，它被理解为数组（array）。
这些都是常见的数据结构。事实上大部分现代计算机语言都以某种形式支持它们,这使得一种数据格式在同样基于这些结构的编程语言之间交换成为可能。
总结到这里systemd journal对系统及应用数据的收集与管理机制就介绍完毕了。其出色的灵活性源自将广泛的元数据自动记录至集中化日志之内。另外 journalctl 命令 则显著简化了journal的使用方式，从而让更多管理员得以利用它完成面向不同应用组件的分析与相关调试工作。
3.Systemd-analyze
1 | #Linux系统开机时间流程所耗费时间一览 |
0x03 补充知识
systemctl 配置文件的设置参数一览:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24[Unit] # 与此 unit 的解释、执行服务相依性有关
Description=描述
Documentation=文档地址
After=network.target #在服务之后
Before=test.target #在服务之前
Wants=sshd-keygen.service #需求服务
Requires=network.target #依赖的服务
Conflicts=冲突解决
[Service] # 这个项目与实际执行的指令参数有关
Type=服务类型
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
RemainAfterExit
TimeoutSec
[Install] # 此 unit 要挂载哪个 target 下面即默认启动的运行级别（自启动设置）
WantedBy=multi-user.target #在何种服务或环境下启动
Also
Alias
1.自定义服务单元
方式1：
描述：为了避免和 pacman 冲突不应该直接编辑软件包提供的文件. 要更改由软件包提供的单元文件，先创建名为/etc/systemd/system/<单元名>.d/ 的文件夹（如 /etc/systemd/system/httpd.service.d/）；然后放入 *.conf 文件，当中能够加入或重置參数，这里设置的參数优先级高于原来的单元文件。
实际案例：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19#1.比如假设想加入一个额外的依赖。创建这么一个文件就可以：
/etc/systemd/system/<unit>.d/customdependency.conf
[Unit]
Requires=<新依赖>
After=<新依赖>
/etc/systemd/system/unit.d/customexec.conf
[Service]
#想知道为什么改动 ExecStart 前必须将其置空
ExecStart=
ExecStart=new command
#自己主动重新启动服务
Restart=always
RestartSec=30
#2.然后执行下面命令使更改生效：
systemctl daemon-reload
systemctl restart <单元>
此外，把旧的单元文件从 /usr/lib/systemd/system/ 拷贝到 /etc/systemd/system/，然后进行改动，也能够达到相同效果。
总结：
在 /etc/systemd/system/ 文件夹中的单元文件的优先级总是高于 /usr/lib/systemd/system/ 文件夹中的同名单元文件
用 systemd-delta 命令来查看哪些单元文件被覆盖、哪些被改动，系统维护的时候须要及时了解哪些单元已经有了更新。
方法2
自定义软件的 Systemd 单元实例:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18[Unit]
Description=WebP Server Go
Documentation=https://github.com/webp-sh/webp_server_go
After=nginx.target
[Service]
User=root
Group=root
Type=simple
StandardError=journal
WorkingDirectory=/opt/webps
#EnvironmentFile=-/etc/etcd/etcd.conf
ExecStart=/opt/webps/webp-server --config /opt/webps/config.json
Restart=always
RestartSec=3s
[Install]
WantedBy=multi-user.target
然后将其保存在/usr/lib/systemd/system/docker.service/webp.service，并且 执行 systemctl daemon-reload重载守护服务; 之后将可以通过systemctl status webp.service 对我们编写的服务单元进行管理;
关于 systemd 的单元配置文件如何书写，因为根据不同的单元类型包含的配置项实在是巨多。建议参考官方文档/社区翻译文档
2.自定义配置
（1）基于systemd实现显示服务CPU 和 Memory 信息 WeiyiGeek.1
2
3
4$vim /etc/systemd/system.conf
DefaultCPUAccounting=yes
DefaultMemoryAccounting=yes
DefaultTasksAccounting=yes
修改重启系统即可看见;
