Systemd

Posted 2021-01-15 link-luck

Centos 7中的systemd：
  概述：
  CentOS 6和之前版本采用SysV init的系统启动进程管理体系，一般用户都可通过在/etc/inittab文件的配置，来个性化自己的系统启动序列。但也经常会由于特殊环境的硬件等关系问题，造成其串行的启动进程控制流，因为可能任务的阻塞而影响启动过程。
  CentOS 7开始使用SystemD，所以我们必须要了解SystemD。本章将从CentOS 7的启动流程、Unit、服务管理，启动排错，破解口令以及修复grub2等方面来介绍Systemd的相关内容。

  系统启动流程
　　POST—> Boot Sequence—> Bootloader—> kernel + initramfs(initrd)—> rootfs(根切换)—> /sbin/init
  init程序：
　　CentOS 5: SysV init
　　CentOS 6: Upstart
　　CentOS 7: Systemd

  Systemd：系统启动和服务器守护进程管理器，负责在系统启动或运行时激活系统资源、服务器进程和其它进程

  Systemd新特性
　系统引导时实现服务并行启动：
　　为了加速整个系统启动和并行启动更多的进程，systemd 在实际启动守护进程之前创建监听socket，然后传递 socket 给守护进程。在系统初始化时，首先为所有守护进程创建 socket ，然后再启动所有的守护进程。如果一个服务因为需要另一个服务的支持而没有完全启动，而这个连接可能正在提供服务的队列中排队，那么这个客户端进程在这次请求中就处于阻塞状态。不过只会有这一个客户端进程会被阻塞，而且仅是在这一次请求中被阻塞。服务间的依赖关系也不再需要通过配置来实现真正的并行启动(因为一次开启了所有的 socket ，如果一个服务需要其他的服务，它显然可以连接到相应的 socket)

  按需启动守护进程：
　　只有在某个服务被真正请求的时候才启动它。当该服务结束，systemd 可以关闭它，等待下次需要时再次启动它。

　自动化的服务依赖关系管理：
　　systemd 支持服务(或 unit)间的多种依赖关系。在 unit 配置文件中使用 After/Before、Requires 和 Wants 选项可以固定 unit 激活的顺序。Requires 和 Wants 表示一个正向(强制或可选)的需求和依赖关系，Conflicts 表示一个负向的需求和依赖关系。其他选项较少用到。如果一个 unit 需要启动或关闭，systemd 就把它和它的依赖关系添加到临时执行列表，然后确认它们的相互关系是否一致(或所有unit 的先后顺序是否含有循环)。如果答案是否的话，systemd 将尝试修复它，删除可以消除循环的无用工作。

　D-Bus 激活策略启动服务：
　　通过使用总线激活策略，服务可以在接入时马上启动。同时，总线激活策略使得系统可以用微小的消耗实现 D-Bus 服务的提供者与消费者的同步开启请求。(同时开启多个服务，如果一个比总线激活策略中其他服务快就在 D-Bus 中排队其请求，直到其他管理确定自己的服务信息为止)

　支持快照和系统状态恢复：
　　快照可以用来保存/恢复系统初始化时所有的服务和 unit 的状态。它有两种主要的使用情况：允许用户暂时进入一个像 "Emergency Shell" 的特殊状态，终止当前的服务；提供一个回到先前状态的简单方法，重新启动先前暂时终止的服务
　　systemd 支持按需启动，因此系统的运行状态是动态变化的，人们无法准确地知道系统当前运行了哪些服务。Systemd 快照提供了一种将当前系统运行状态保存并恢复的能力。
　　比如系统当前正运行服务 A 和 B，可以用 systemd 命令行对当前系统运行状况创建快照。然后将进程 A 停止，或者做其他的任意的对系统的改变，比如启动新的进程 C。在这些改变之后，运行 systemd 的快照恢复命令，就可立即将系统恢复到快照时刻的状态，即只有服务 A，B 在运行。一个可能的应用场景是调试：比如服务器出现一些异常，为了调试用户将当前状态保存为快照，然后可以进行任意的操作，比如停止服务等等。等调试结束，恢复快照即可。
　　这个快照功能目前在 systemd 中并不完善，似乎开发人员也没有特别关注它，因此有报告指出它还存在一些使用上的问题，使用时尚需慎重。

  维护挂载和自挂载点：
　　systemd 监视所有的挂载点的进出情况，也可以用来挂载或卸载挂载点。/etc/fstab 也可以作为这些挂载点的一个附加配置源。通过使用 comment= fstab 选项可以标记 /etc/fstab 条目使其成为由 systemd 控制的自挂载点。
　　传统的 Linux 系统中，用户可以用/etc/fstab 文件来维护固定的文件系统挂载点。这些挂载点在系统启动过程中被自动挂载，一旦启动过程结束，这些挂载点就会确保存在。这些挂载点都是对系统运行至关重要的文件系统，比如 HOME 目录。和 sysvinit 一样，Systemd 管理这些挂载点，以便能够在系统启动时自动挂载它们。Systemd 还兼容/etc/fstab 文件，您可以继续使用该文件管理挂载点。
　　有时候用户还需要动态挂载点，比如打算访问 DVD 内容时，才临时执行挂载以便访问其中的内容，而不访问光盘时该挂载点被取消(umount)，以便节约资源。传统地，人们依赖 autofs 服务来实现这种功能。Systemd 内建了自动挂载服务，无需另外安装 autofs 服务，可以直接使用 systemd 提供的自动挂载管理能力来实现 autofs 的功能

  采用 Linux的Cgroup特性跟踪和管理进程的生命周期：
　　systemd 则利用了 Linux 内核的特性即 CGroup 来完成跟踪的任务。当停止服务时，通过查询 CGroup，systemd 可以确保找到所有的相关进程，从而干净地停止服务。
　　CGroup 已经出现了很久，它主要用来实现系统资源配额管理。CGroup 提供了类似文件系统的接口，使用方便。当进程创建子进程时，子进程会继承父进程的 CGroup。因此无论服务如何启动新的子进程，所有的这些相关进程都会属于同一个 CGroup，systemd 只需要简单地遍历指定的 CGroup 即可正确地找到所有的相关进程，将它们一一停止即可。

  日志服务
　　systemd 自带日志服务 journald，该日志服务的设计初衷是克服现有的 syslog 服务的缺点。比如：
　　syslog 不安全，消息的内容无法验证。每一个本地进程都可以声称自己是 Apache PID 4711，而 syslog 也就相信并保存到磁盘上。
数据没有严格的格式，非常随意。自动化的日志分析器需要分析人类语言字符串来识别消息。一方面此类分析困难低效；此外日志格式的变化会导致分析代码需要更新甚至重写。
　　Systemd Journal 用二进制格式保存所有日志信息，用户使用 journalctl 命令来查看日志信息。无需自己编写复杂脆弱的字符串分析处理程序。
　　Systemd Journal 的优点如下：
????简单性：代码少，依赖少，抽象开销最小。
????零维护：日志是除错和监控系统的核心功能，因此它自己不能再产生问题。举例说，自动管理磁盘空间，避免由于日志的不断产生而将磁盘空间耗尽。
????移植性：日志文件应该在所有类型的 Linux 系统上可用，无论它使用的何种 CPU 或者字节序。
????性能：添加和浏览日志非常快。
????最小资源占用：日志数据文件需要较小。
????统一化：各种不同的日志存储技术应该统一起来，将所有的可记录事件保存在同一个数据存储中。所以日志内容的全局上下文都会被保存并且可供日后查询。例如一条固件记录后通常会跟随一条内核记录，最终还会有一条用户态记录。重要的是当保存到硬盘上时这三者之间的关系不会丢失。Syslog 将不同的信息保存到不同的文件中，分析的时候很难确定哪些条目是相关的。
????扩展性：日志的适用范围很广，从嵌入式设备到超级计算机集群都可以满足需求。
????安全性：日志文件是可以验证的，让无法检测的修改不再可能。

systemd关键特性：
  基于套接字(socket-based)的触发激活：
　　与服务相关的套接字，从守护进程中剥离出来，目的是为了更好的分开来进行处理。这么做有很多好处：比如我们可以对服务延迟启动，直到其相关的套接字可用为止。比如这么做可以允许系统在服务启动过程之前先创建好套接字，从而使得能够并行启动该服务的相关服务。
　　systemd为支持此机制的服务监听socket，当有客户端与socket通信时，由systemd激活服务，应答客户端的请求；这种机制类似于守护进程

　　基于总线(bus-based)的触发激活：
　　unit也可以被D-Bus提供的总线接口激活。当一个与某个单元相关的总线被发布的时候，该单元便可以开始工作

  基于device的触发激活机制：
　　当有设备接入时，systemd会自动激活device、mount、automount等unit来识别，挂载接入的设备

  基于path的触发激活机制：
　　一个unit可以依据某个确定的文件系统路径的活动状态以及可用性而开始工作。相当于集成了Linux的inotify功能
　　当某个文件路径变得可用时或路径出现相应文件时，激活对应服务

兼容性：
  向后兼容sysvinit脚本：
  　兼容CentOS 5的sysV init以及CentOS 6的upstart机制，也就是说可以继续将服务管理脚本放入/etc/rc.d/init.d目录中管理

  systemd与sysV init 以及upstart不兼容之处：
　　1、/etc/rc.d/init.d目录中的服务管理脚本不可以用systemctl命令来管理，systemctl命令的参数已经固定
　　2、/etc/rc.d/init.d目录中的服务管理脚本启动的服务，与systemd管理启动的进程之间无法通信
　　3、systemd虽然模拟出run level，但是与init、upstart机制的运行级别不完全一致

核心概念：Unit
  unit表示不同类型的systemd对象，通过配置文件进行标识和配置；文件中主要包含了系统服务、监听socket、保存的系统快照以及其它与init相关的信息；
  系统初始化需要做的事情非常多。需要启动后台服务，比如启动SSHD服务；需要做配置工作，比如挂载文件系统。这个过程中的每一步都被systemd抽象为一个配置单元，即 unit。可以认为一个服务是一个配置单元；一个挂载点是一个配置单元；一个交换分区的配置是一个配置单元；systemd 将配置单元归纳为以下一些不同的类型。然而systemd正在快速发展，新功能不断增加。所以配置单元类型可能在不久的将来继续增加。

  systemctl -t help 查看unit类型
演示：
[[email protected] ~]# systemctl -t help
Available unit types:
service
socket
busname
target
snapshot
device
mount
automount
swap
timer
path
slice
scope

  service ：
　　文件扩展名为.service, 用于定义系统服务
　　代表一个后台服务进程，比如mysqld。这是最常用的一类。
????
　socket ：
　　文件扩展名为.socket, 用于标识进程间通信用的socket文件，也可在系统启动时，延迟启动服务，实现按需启动
　　此类配置单元封装系统和互联网中的一个套接字 。当下，systemd支持流式、数据报和连续包的AF_INET、AF_INET6、AF_UNIX socket。每一个套接字配置单元都有一个相应的服务配置单元。相应的服务在第一个"连接"进入套接字时就会启动(例如：nscd.socket 在有新连接后便启动 nscd.service)。

  device ：
　　文件扩展名为.device, 用于定义内核识别的设备
　　此类配置单元封装一个存在于 Linux 设备树中的设备。每一个使用 udev 规则标记的设备都将会在 systemd 中作为一个设备配置单元出现。

  mount ：
　　文件扩展名为.mount, 定义文件系统挂载点
　　此类配置单元封装文件系统结构层次中的一个挂载点。Systemd 将对这个挂载点进行监控和管理。比如可以在启动时自动将其挂载；可以在某些条件下自动卸载。Systemd 会将/etc/fstab 中的条目都转换为挂载点，并在开机时处理。

  automount ：
　　文件扩展名为.automount，文件系统的自动挂载点
　　此类配置单元封装系统结构层次中的一个自挂载点。每一个自挂载配置单元对应一个挂载配置单元 ，当该自动挂载点被访问时，systemd 执行挂载点中定义的挂载行为。

  swap:
　　文件扩展名为.swap, 用于标识swap设备
　　和挂载配置单元类似，交换配置单元用来管理交换分区。用户可以用交换配置单元来定义系统中的交换分区，可以让这些交换分区在启动时被激活。

  target ：
　　文件扩展名为.target，用于模拟实现“运行级别”
　　此类配置单元为其他配置单元进行逻辑分组。它们本身实际上并不做什么，只是引用其他配置单元而已。这样便可以对配置单元做一个统一的控制。这样就可以实现大家都已经非常熟悉的运行级别概念。比如想让系统进入图形化模式，需要运行许多服务和配置命令，这些操作都由一个个配置单元表示，将所有这些配置单元组合为一个目标(target)，就表示需要将这些配置单元全部执行一遍以便进入目标所代表的系统运行状态。 (例如：multi-user.target 相当于在传统使用 SysV 的系统中运行级别 5)

  timer：
　　文件扩展名为.timer
　　定时器配置单元用来定时触发用户定义的操作，这类配置单元取代了 atd、crond 等传统的定时服务。

  snapshot ：
　　文件扩展名为.snapshot, 管理系统快照
　　与 target 配置单元相似，快照是一组配置单元。它保存了系统当前的运行状态。

  path：
　　文件扩展名为.path，用于定义文件系统中的一个文件或目录使用,常用于当文件系统变化时，延迟激活服务，如：spool 目录
　　定义了可以被基于路径的触发激活所使用的路径。默认情况下，当路径到了指定的状态(切换到了指定的路径)，一个同名的.service文件将会启用。这里是采用inotify去监控路径的改变

  slice：
　　文件扩展名为.slice：与Linux的CGroup相关。其名称反应了其在cgroup树的层次。默认情况下，单元依据其类型的不同被放置在一定的slice里面。

  scope：
　　文件扩展名为.scope：Scope单元由systemd接收到总线接口的信息而自动生成。这些Scope单元用于管理由外部创建的系统进程(非Systemd 启动的外部进程)。

配置文件：
　/etc/systemd/system/：
　　存放系统启动的默认级别及启动的unit的软连接，优先级最高，类似于/etc/rc.d/rcN.d/S*类的功能
　　Systemd 默认从目录/etc/systemd/system/读取配置文件。但是里面存放的大部分文件都是符号链接指向目录/usr/lib/systemd/system/
　　systemctl enable命令用于在上面两个目录之间建立符号链接关系
　　示例：
　　/etc/systemd/system/vsftpd.service.wants/*：此目录内的文件为链接档，设定相依服务的连结。意思是启动了vsftpd.service之后，最好再加上这目录底下建议的服务
　　/etc/systemd/system/vsftpd.service.requires/*：此目录内的文件为链接档，设定相依服务的连结。意思是在启动vsftpd.service之前，需要事先启动哪些服务的意思

  /run/systemd/system/：
　　系统执行过程中所产生系统单元，优先级次之

  /usr/lib/systemd/system/：
　　存放系统上所有的启动文件，优先级最低；类似于之前的/etc/init.d/

service类型的unit管理
  service类型的unit：
　　启动：service name start ==> systemctl start name.service
　　停止：service name stop ==> systemctl stop name.service
　　重启：service name restart ==> systemctl restart name.service
　　状态：service name status ==> systemctl status name.service
　　显示远端主机服务状态：systemctl -H [email protected] status name.service
　　条件式重启：service name condrestart ==> systemctl try-restart name.service(如果服务是启动状态就不操作，如果是停止状态就启动它)
　　杀死服务及其子进程：systemctl kill name.service
　　重载服务的配置：sudo systemctl reload name.service
　　重载所有修改过的配置文件：systemctl daemon-reload
　　重载或重启服务：systemctl reload-or-restart name.service
　　重载或条件式重启服务：systemctl reload-or-try-restart name.service
　　禁止设定为开机自启：systemctl mask name.service
　　取消禁止设定为开机自启：systemctl unmask name.service
　　显示某个 Unit 的所有底层参数：systemctl show name.service
　　显示某个 Unit 的指定属性的值：systemctl show -p CPUShares httpd.service
　　设置某个 Unit 的指定属性：systemctl set-property httpd.service CPUShares=500

  service类型的unit状态查看：
　　查看某服务是否处于激活的状态
　　systemctl is-active name.service
　　查看某服务是否处于启动失败状态
　　systemctl is-failed name.service
　　查看所有已经激活的服务
　　systemctl list-units --type service或systemctl list-units -t service
　　查看所有服务(已激活及未激活)：
　　systemctl list-units --type service --all或systemctl list-units -t service -a
　　显示某个服务是否建立了启动链接(开机启动)
　　systemctl is-enabled name.service
????
　　service类型的unit状态：
　　loaded：Unit配置文件已处理
　　active(running)：一次或多次持续处理的运行
　　active(exited)：成功完成一次性的配置
　　active(waiting)：运行中，等待一个事件
　　inactive(dead)：不运行
??
  units状态查看：
　　列出正在运行的Unit：
　　systemctl list-units
　　列出所有Unit，包括没有找到配置文件的或者启动失败的：
　　systemctl list-units --all
　　列出所有没有运行的Unit：
　　systemctl list-units --all --state=inactive
　　列出所有加载失败的 Unit：
　　systemctl list-units --failed
　　列出所有正在运行的、类型为service的Unit：
　　systemctl list-units --type=service

  service类型的unit开机启动设置：
　　设定某服务开机自启：
　　chkconfig name on ==> systemctl enable name.service
　　设定某服务开机禁止启动：
　　chkconfig name off ==> systemctl disable name.service
　　查看所有服务的开机自启状态：
　　chkconfig --list ==> systemctl list-unit-files --type service
　　用来列出该服务在哪些运行级别下启用和禁用
　　chkconfig sshd --list==> ls /etc/systemd/system/*.wants/sshd.service
　　查看服务能否开机自启：
　　chkconfig --list name ==> systemctl is-enabled name.service
　　查看服务的依赖关系：
　　systemctll ist-dependencies name.service
　　上面命令的输出结果之中，有些依赖是Target类型，默认不会显示。如果要显示Target，就需要使用--all参数。
　　systemctl list-dependencies --all name.service

　　开机启动状态：
　　enabled：开机启动(已建立启动链接)
　　disabled：开机不启动(没建立启动链接)
　　static：开机不启动，该配置文件没有[Install]部分(无法执行)，只能作为其他配置文件的依赖??
　　masked：该配置文件被禁止建立启动链接

  service类型的unit配置文件：
  文件位置：
　　/etc/systemd/system：系统管理员和用户使用
　　/usr/lib/systemd/system：发行版打包者使用
  文件说明：
　　以"#"开头的行被认为是注释
　　相关布尔值，1、yes、on、true都是开启，0、no、off、false都是关闭
　　时间单位默认是秒，要用毫秒(ms)分钟(m)明确指定单位
　　配置文件的区块名、字段名都大小写敏感；每个区块内部是等号连接的键值对，键值对与等号两侧不能有空格

  配置文件就是普通的文本文件，可以用文本编辑器打开。也可以通过以下命令指定服务的配置文件内容。
　　systemctl cat name.service

  service unit file文件通常由三部分组成：
　　[Unit]：定义与Unit类型无关的通用选项；用于提供unit的描述信息、unit行为及依赖关系等;
　　[Service]：与特定类型相关的专用选项；此处为Service类型
　　[Install]：定义由"systemctl enable"以及"systemctl disable"命令在实现服务开机启用或禁用时用到的一些选项

  [Unit]：区块通常是配置文件的第一个区块，用来定义Unit的元数据，以及配置与其他Unit的关系。主要字段如下：
　　Description：简短描述
　　Documentation：文档地址
　　equires：当前Unit依赖的其他Unit，如果它们没有运行，当前Unit会启动失败(强依赖)
　　Wants：与当前Unit配合的其他 Unit，如果它们没有运行，当前Unit不会启动失败(弱依赖)
　　BindsTo：与Requires类似，它指定的Unit如果退出，会导致当前Unit停止运行
　　Before：如果该字段指定的Unit也要启动，那么必须在当前Unit之后启动
　　After：如果该字段指定的Unit也要启动，那么必须在当前Unit之前启动
　　Conflicts：这里指定的Unit不能与当前Unit同时运行
　　Condition...：当前Unit运行必须满足的条件，否则不会运行
　　Assert...：当前Unit运行必须满足的条件，否则会报启动失败

  注意：After和Before字段只涉及启动顺序，不涉及依赖关系；设置依赖关系，需要使用Wants字段和Requires字段；Wants字段与Requires字段只涉及依赖关系，与启动顺序无关，默认情况下是同时启动的

  [Install]：通常是配置文件的最后一个区块，用来定义如何启动，以及是否开机启动。主要字段如下：
　　WantedBy：它的值是一个或多个Target，当前Unit激活时(enable)符号链接会放入/etc/systemd/system目录下面以Target名+.wants后缀构成的子目录中
　　RequiredBy：它的值是一个或多个Target，当前Unit激活时，符号链接会放入/etc/systemd/system目录下面以Target名+.required后缀构成的子目录中
　　Alias：当前Unit可用于启动的别名
　　Also：当前Unit激活(enable)时，会被同时激活的其它Unit

  [Service]：区块是Service的配置，只有Service类型的Unit才有这个区块。主要字段如下：
　　Type：定义启动时的进程行为。它有以下几种值。
　　　　Type=simple：默认值，ExecStart字段启动的进程为主进程
　　　　Type=forking：ExecStart字段将以fork()方式启动(从父进程创建子进程)，此时父进程将会退出，子进程成为主进程
　　　　Type=oneshot：类似于simple，但只执行一次，Systemd 会等它执行完，才启动其他服务
　　　　Type=dbus：类似于simple，但会等待 D-Bus信号后启动(通过D-Bus启动)
　　　　Type=notify：类似于simple，当前服务启动完毕后会发通知信号给Systemd，然后Systemd再启动其他服务
　　　　Type=idle：类似于simple，但是要等到其他任务都执行完，才会启动该服务。一种使用场合是为让该服务的输出，不与其他服务的输出相混合
　　ExecStart：启动当前服务的命令
　　ExecStartPre：启动当前服务之前执行的命令
　　ExecStartPost：启动当前服务之后执行的命令
　　ExecReload：重启当前服务时执行的命令
　　ExecStop：停止当前服务时执行的命令
　　ExecStopPost：停止当其服务之后执行的命令
　　RestartSec：自动重启当前服务间隔的秒数
　　Restart：定义何种情况Systemd会自动重启当前服务，可能的值包括always(总是重启)、on-success、on-failure、on-abnormal、on-abort、on-watchdog
　　TimeoutSec：定义Systemd停止当前服务之前等待的秒数
　　Environment：指定环境变量
　　EnvironmentFile：指定当前服务的环境参数文件。该文件内部的key=value键值对，可以用$key的形式，在当前配置文件中获取

target类型unit管理：
  启动计算机的时候，需要启动大量的Unit。如果每一次启动，都要一一写明本次启动需要哪些Unit，显然非常不方便。Systemd的解决方案就是 Target。简单说，Target就是一个Unit 组，包含许多相关的Unit。启动某个Target的时候，Systemd就会启动里面所有的 Unit。从这个意义上说，Target 这个概念类似于"状态点"，启动某个 Target 就好比启动到某种状态。
  传统的init启动模式里面，有RunLevel的概念，跟Target的作用很类似。不同的是RunLevel 是互斥的，不可能多个 RunLevel 同时启动，但是多个 Target可以同时启动。

  target类型unit配置文件：
　　/usr/lib/systemd/system/*.target

  Target与传统RunLevel 的对应关系如下：
　　Traditional runlevel New target name     Symbolically linked to...
　　Runlevel 0 　　　　| runlevel0.target -> poweroff.target   关机
　　Runlevel 1 　　　　| runlevel1.target -> rescue.target     单用户模式或者救援模式
　　Runlevel 2 　　　　| runlevel2.target -> multi-user.target
　　Runlevel 3 　　　　| runlevel3.target -> multi-user.target 正常多用户命令行模式
　　Runlevel 4 　　　　| runlevel4.target -> multi-user.target
　　Runlevel 5 　　　　| runlevel5.target -> graphical.target  正常多用户图形模式
　　Runlevel 6 　　　　| runlevel6.target -> reboot.target     重启

  查看当前系统的所有Target开机启动状态
　　systemctl list-unit-files --type target
　　systemctl list-unit-files --type target --all
  查看一个Target包含的所有Unit(依赖关系)
　　systemctl list-dependencies multi-user.target
　　systemctl list-dependencies graphical.target

  运行级别切换：
　　init N ==> systemctl isolate name.target
　　systemctl isolate multi-user.target 切换到级别3
　　systemctl isolate graphical.target 切换到级别5
　注意：
　　1、只有/lib/systemd/system/*.target文件中AllowIsolate=yes才能切换(修改文件需执行systemctl daemon-reload才能生效)
　　2、切换Target时，默认不关闭前一个Target启动的进程，systemctl isolate命令改变这种行为，关闭前一个Target里面所有不属于后一个 Target 的进程
  查看运行级别(查看所有激活的target)：
　　runlevel，who -r ==> systemctl list-units --type target
  获取默认运行级别(查看启动时的默认Target)：
　　/etc/inittab ==> systemctl get-default
  设置默认运行级别(设置启动时的默认 Target)：
　　/etc/inittab==> systemctl set-default name.target
　　systemctl set-default multi-user.target 修改为3级别
　　systemctl set-default graphical.target 修改为5级别

  target与init进程的主要差别：
　　1、默认的RunLevel(在/etc/inittab文件设置)现在被默认的Target取代，位置是/etc/systemd/system/default.target，通常符号链接到graphical.target(图形界面)或者multi-user.target(多用户命令行)
　　2、启动脚本的位置，以前是/etc/init.d目录，符号链接到不同的RunLevel目录(比如/etc/rc3.d、/etc/rc5.d等)，现在则存放在/lib/systemd/system和/etc/systemd/system目录。
　　3、配置文件的位置，以前init进程的配置文件是/etc/inittab，各种服务的配置文件存放在/etc/sysconfig目录。现在的配置文件主要存放在/lib/systemd目录，在/etc/systemd目录里面的修改可以覆盖原始设置。

  target类型的unit配置文件：

systemd系统管理类命令：
  Systemd并不是一个命令，而是一组命令，涉及到系统管理的方方面面。systemctl是Systemd 的主命令，用于管理系统。

  切换至紧急救援模式：
　　systemctl rescue
  切换至emergency(紧急)模式：
　　systemctl emergency

  传统命令init、poweroff、halt、reboot都成为systemctl的软链接
  重启系统：
　　systemctl reboot
  关闭系统，切断电源：
　　systemctl poweroff
  CPU停止工作：
　　systemctl halt
  挂起系统：睡眠模式(也叫挂起suspend)，把信息保存到内存中，断电数据丢失，但是恢复时较快
　　systemctl suspend
  让系统进入休眠状态：休眠模式把信息写入到文件中(也就是硬盘中)，断电数据不丢失，但是恢复时较慢，像重新开机一样
　　systemctl hibernate
  让系统进入混合休眠状态：是指suspend(睡眠模式)和hibernate(休眠模式)同时进行，即把信息保存到内存的同时也写入到系统主分区的hiberfil. sys文件中
　　systemctl hybrid-sleep

  systemd-analyze命令用于查看启动耗时。
  查看启动耗时：
　　systemd-analyze
  查看每个服务的启动耗时：
　　systemd-analyze blame
  显示瀑布状的启动过程流：
　　systemd-analyze critical-chain
  显示指定服务的启动流：
　　systemd-analyze critical-chain name.service

  hostnamectl命令用于查看当前主机的信息。
  显示当前主机的信息
　　hostnamectl
  设置主机名。
　　hostnamectl set-hostname New_Hostname

  localectl命令用于查看本地化设置。
  查看本地化设置
　　localectl
  设置本地化参数。
　　localectl set-locale LANG=en_US.utf8
　　localectl set-keymap en_US

  timedatectl命令用于查看当前时区设置。
  查看当前时区设置
　　timedatectl
  显示所有可用的时区
　　timedatectl list-timezones
  设置当前时区
　　timedatectl set-timezone Asia/Shanghai
　　timedatectl set-time YYYY-MM-DD
　　timedatectl set-time HH:MM:SS

  loginctl命令用于查看当前登录的用户。
  列出当前session
　　loginctl list-sessions
  列出当前登录用户
　　loginctl list-users
  列出显示指定用户的信息
　　loginctl show-user Username

日志管理
  Systemd统一管理所有Unit的启动日志。带来的好处就是，可以只用journalctl一个命令，查看所有日志(内核日志和应用日志)。日志的配置文件是/etc/systemd/journald.conf；journalctl功能强大，用法非常多。

  查看所有日志(默认情况下 ，只保存本次启动的日志)
　　journalctl
  查看内核日志(不显示应用日志)
　　journalctl -k

  查看系统本次启动的日志
　　journalctl -b
　　journalctl -b -0
  查看上一次启动的日志(需更改设置)
　　journalctl -b -1

  查看指定时间的日志
　　journalctl --since="2012-10-30 18:17:16"
　　journalctl --since "20 min ago"
　　journalctl --since yesterday
　　journalctl --since "2015-01-10" --until "2015-01-11 03:00"
　　journalctl --since 09:00 --until "1 hour ago"

  显示尾部的最新10行日志
　　journalctl -n
  显示尾部指定行数的日志
　　journalctl -n 20
  实时滚动显示最新日志
　　journalctl -f

  查看指定服务的日志
　　journalctl /usr/lib/systemd/systemd
  查看指定进程的日志
　　journalctl _PID=1
  查看某个路径的脚本的日志
　　journalctl /usr/bin/bash
  查看指定用户的日志
　　journalctl _UID=33 --since today
  查看某个 Unit 的日志
　　journalctl -u name.service
　　journalctl -u name.service --since today
  实时滚动显示某个 Unit 的最新日志
　　journalctl -u name.service -f
  合并显示多个 Unit 的日志
　　journalctl -u name1.service -u name2.service --since today

  查看指定日志级别的日志，共有8级
　　journalctl -p err -b
????0: emerg
????1: alert
????2: crit
????3: err
????4: warning
????5: notice
????6: info
????7: debug

  日志默认分页输出，--no-pager改为正常的标准输出
　　journalctl --no-pager

  以JSON格式(单行)输出
　　journalctl -b -u name.service -o json
  以JSON格式(多行)输出，可读性更好
　　journalctl -b -u name.service -o json-pretty

  显示日志占据的硬盘空间
　　journalctl --disk-usage
  指定日志文件占据的最大空间
　　journalctl --vacuum-size=1G
  指定日志文件保存多久
　　journalctl --vacuum-time=1years

CentOS 7 引导顺序
  UEFI或Bios初始化，运行POST开机自检
  选择启动设备
  引导装载程序，centos7是grub2
  加载装载程序的配置文件：/etc/grub.d/ /etc/default/grub /boot/grub2/grub.cfg
  加载initramfs驱动模块
  加载内核选项
  内核初始化，Centos7使用systemd代替init
  执行initrd.target所有单元，包括挂载/etc/fstab
  从initramfs根文件系统切换到磁盘根目录
  systemd执行默认target配置，配置文件/etc/systemd/default.target /etc/systemd/system/
  systemd执行sysinit.target初始化系统及basic.target准备操作系统
  systemd启动multi-user.target下的本机与服务器服务
  systemd执行multi-user.target下的/etc/rc.d/rc.local
  systemd执行multi-user.target下的getty.target及登入服务
  systemd执行graphical需要的服务

1、设置内核参数：
  设置内核参数，只影响当次启动；启动时，在linux16行后添加
　　systemd.unit=desired.target
　　systemd.unit=emergency.target
　　systemd.unit=recure.target
　　recure.target 比emergency 支持更多的功能，例如日志等

2、启动排错：
  文件系统损坏；先尝试自动修复，失败则进入emergency shell，提示用户修复
  在/etc/fstab不存在对应的设备和UUID；等一段时间，如不可用，进入emergency shell
  在/etc/fstab不存在对应挂载点；systemd尝试创建挂载点，否则提示进入emergency shell
  在/etc/fstab不正确的挂载选项；提示进入emergency shell

3、破解root密码：
  启动时任意键暂停启动
  按e键进入编辑模式
  将光标移动到linux16开始的行，添加内核参数rd.break
  按ctrl+x启动
　　mount -o remount,rw /systoot 默认启动为只读挂载，重新挂载为读写
　　chroot /sysroot 切换到真正文件系统的根
　　passwd root 设置root密码
　　touch /.autorelabel 要重新打标签，触发selinux策略

4、修复GRUB2
  主配置文件：/boot/grub2/grub.cfg
  修复配置文件：grub2-mkconfig > /boot/grub2/grub.cfg
  修复grub：
　　grub2-install /dev/sda BIOS环境下
　　grub2-install UEFI环境下