未能加载程序集或它的一个依赖项_linux服务管理程序systemd

systemd是Linux操作系统的系统和管理服务程序，作为系统启动的第一个进程（进程id为1)，用于初始化系统，启动和维护用户空间服务。

为了与sysv(Sysvinit:较早的系统启动管理服务)兼容，如果systemd被当作init并且pid不是1，它将执行telinit(用来改变SysV的运行级别)并传递所有未修改的命令行参数。这意味着当从正常登录会话调用init和telinit时，它们基本上是等价的。

当作为系统实例运行时，systemd将解释system.conf配置文件和system.conf.d目录中的文件。

systemd提供了一个12种不同类型的实体被称作“units”的依赖系统。单元封装了各种相关的对象用于系统启动和维护。大多数单元配置在单元配置文件，描述其语法和基本选项集，但是有些是从其他配置，正在运行的系统状态或以编程方式动态地进行配置。单元可以是“活动的”（意思是启动、绑定、插入等，具体取决于单位类型，见下文）或“不活动”（表示已停止、未绑定，拔掉，…），以及在被激活或停用的过程中，即在两种状态之间（这些状态称为“激活”，“停用”）。一个特殊的“失败”状态也可用，这是非常类似于“不活动”，当服务以某种方式失败时输入（进程在退出时返回错误代码，或崩溃，或操作超时）。如果输入此状态，则会记录原因，以供以后参考。注释不同的单元类型可能有一些附加的子状态，这些子状态映射到这里描述的五个广义单元状态。

下列十二种单元类型是可用的：

1. Service units：服务单元，启动和控制守护进程及它们包含的进程。有关详细信息，请参阅systemd.service。

2. Socket units：套接字单元，将本地IPC或网络套接字封装在系统，用于激活套接字。

3. Target units：目标单元，用于单元组，为系统启动期间提供同步点。

4. Device units ：设备单元，在systemd中公开内核设备，并可用于实现基于设备的激活。有关详细信息，请参阅systemd.device。

5. Mount units：挂载单元，控制文件系统中的挂载点。

6. Automount units：自动挂载单元，提供自动挂载功能，用于按需挂载文件系统以及并行启动。请参阅systemd.automount。

7. Snapshot units：快照单元，可用于临时保存系统单元集合的状态，稍后会保存激活的快照单元。请参见systemd.snapshot。

8. Timer units：计时器单元，基于计时器用于触发激活其他单元。请参见systemd.timer。

9. Swap units：交换单元，非常类似于挂载单元和封装内存交换分区或操作系统文件。

10. Path units：路径单元，当文件系统对象被改变或修改来激活其他服务。

11. Slice units：切片单元,可用于对管理系统过程的单元进行分组(如服务和作用域单元）在资源管理的层次树中。

12. Scope units：作用域单元，类似于服务单元，但它管理外部进程而不是启动它们。

应用程序和单元（通过依赖项）可以请求改变单元的状态。在systemd中，这些请求被封装为“jobs”和在作业队列中维护。工作可能成功，也可能失败，它们执行的顺序是基于它们所属单元之间的排序依赖关系排序而定的。

一.systemctl是Systemd的主命令，用于对系统进行管理。相当于将 service 和 chkconfig 这两个命令组合到一起。

如：systemctl reboot //重启电源

systemctl poweroff //关闭系统，切断电源

二.systemd-analyze命令用于查看启动耗时。

systemd-analyze //查看启动耗时

systemd-analyze blame //查看每个服务的耗时

systemd-analyze critical-chain //显示瀑布状的启动过程流

systemd-analyze critical-chain atd.service //显示指定服务的启动流

三.hostnamctl命令用于查看当前主机的信息。

hostnamectl //显示当前主机的信息(hostname值显示主机名）

hostnamectl set-hostname ceshi //设置主机名(hostname ceshi)

四.localectl命令用于查看本地化设置。

localectl //查看本地话设置

localectl set-locale LANG=en_GB.utf8

lsocalectl set-keymap en_GB

# 列出正在运行的 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

2）Unit的状态

systemctl status 命令用于查看系统状态和单个Unit的状态。

# 显示系统状态

systemctl status

# 显示单个 Unit 的状态

sysystemctl status redis.service

# 显示某个 Unit 是否正在运行

systemctl is-active application.service

# 显示某个 Unit 是否处于启动失败状态

systemctl is-failed redis.service

# 显示某个 Unit 服务是否建立了启动链接

systemctl is-enabled redis.service

3)unit管理

对于用户来说，最常用的是下面这些命令，用于启动和停止 Unit（主要是 service）。

# 立即启动一个服务

systemctl start nginx.service

# 立即停止一个服务

systemctl stop nginx.service

# 重启一个服务

systemctl restart nginx.service

# 杀死一个服务的所有子进程

systemctl kill nginx.service

# 重新加载一个服务的配置文件

systemctl reload nginx.service

# 重载所有修改过的配置文件

systemctl daemon-reload

# 显示某个 Unit 的所有底层参数

systemctl show nginx.service

# 显示某个 Unit 的指定属性的值

systemctl show -p CPUShares nginx.service

# 设置某个 Unit 的指定属性

systemctl set-property nginx.service CPUShares=500

4)unit依赖关系

Unit之间存在依赖关系：A依赖于B，就意味着 Systemd 在启动A 的时候，同时会去启动B。

systemctl list-dependencies命令列出一个 Unit 的所有依赖。

systemctl list-dependencies nginx.service

上面命令的输出结果之中，有些依赖是 Target 类型，默认不会展开显示。如果要展开 Target，就需要使用--all参数。

systemctl list-dependencies --all nginx.service

Unit配置文件：

1.每一个 Unit 都有一个配置文件，告诉 Systemd 怎么启动这个 Unit 。

Systemd 默认从目录/etc/systemd/system/读取配置文件。但是，里面存放的大部分文件都是符号链接，指向目录/usr/lib/systemd/system/，真正的配置文件存放在那个目录。

systemctl enable命令用于在上面两个目录之间，建立符号链接关系。

systemctl enable redis.service等同于ln -s '/usr/lib/systemd/system/redis.service' '/etc/systemd/system/multi-user.target.wants/redis.service'

如果配置文件里面设置了开机启动，systemctl enable命令相当于激活开机启动。

与之对应的，systemctl disable命令用于在两个目录之间，撤销符号链接关系，相当于撤销开机启动。

$ sudo systemctl disable redis.service

配置文件的后缀名，就是该 Unit 的种类，比如sshd.socket。如果省略，Systemd 默认后缀名为.service，所以sshd会被理解成sshd.service。

2.配置文件的状态

systemctl list-unit-files命令用于列出所有配置文件。

# 列出所有配置文件

$ systemctl list-unit-files

# 列出指定类型的配置文件

systemctl list-unit-files --type=service

systemctl list-unit-files

这个列表显示每个配置文件的状态，一共有四种。

enabled：已建立启动链接

disabled：没建立启动链接

static：该配置文件没有[Install]部分（无法执行），只能作为其他配置文件的依赖

masked：该配置文件被禁止建立启动链接

注意，从配置文件的状态无法看出，该 Unit 是否正在运行。这必须执行前面提到的systemctl status命令。

systemctl status redis.service

一旦修改配置文件，就要让 Systemd重新加载配置文件，然后重新启动，否则修改不会生效。

systemctl daemon-reload

systemctl restart redis.service

3.配置文件的格式

systemctl cat命令可以查看配置文件的内容。

$ systemctl cat redis.service

[Unit]

Description=Redis persistent key-value database

After=network.target

After=network-online.target

Wants=network-online.target

[Service]

ExecStart=/usr/bin/redis-server /etc/redis.conf --supervised systemd

ExecStop=/usr/libexec/redis-shutdown

Type=notify

User=redis

Group=redis

RuntimeDirectory=redis

RuntimeDirectoryMode=0755

[Install]

WantedBy=multi-user.target

从上面的输出可以看到，配置文件分成几个区块。每个区块的第一行，是用方括号表示的区块名，比如[Unit]。

每个区块内部是一些等号连接的键值对。

[Section]

Directive1=value

Directive2=value

. . .

注意，键值对的等号两侧不能有空格。

4.配置文件的区块

[Unit]区块通常是配置文件的第一个区块，用来定义 Unit 的元数据，以及配置与其他 Unit 的关系。它的主要字段如下。

Description：简短描述

Documentation：文档地址

Requires：当前 Unit 依赖的其他 Unit，如果它们没有运行，当前 Unit 会启动失败

Wants：与当前 Unit 配合的其他 Unit，如果它们没有运行，当前 Unit 不会启动失败

BindsTo：与Requires类似，它指定的Unit如果退出，会导致当前Unit停止运行

Before：如果该字段指定的Unit也要启动，那么必须在当前Unit之后启动

After：如果该字段指定的Unit也要启动，那么必须在当前Unit之前启动

Conflicts：这里指定的Unit不能与当前Unit同时运行

Condition...：当前Unit运行必须满足的条件，否则不会运行

Assert...：当前 Unit 运行必须满足的条件，否则会报启动失败

[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：以 fork 方式从父进程创建子进程，创建后父进程会立即退出

Type=oneshot：一次性进程，Systemd 会等当前服务退出，再继续往下执行

Type=dbus：当前服务通过D-Bus启动

Type=notify：当前服务启动完毕，会通知Systemd，再继续往下执行

Type=idle：若有其他任务执行完毕，当前服务才会运行

ExecStart：启动当前服务的命令

ExecStartPre：启动当前服务之前执行的命令

ExecStartPost：启动当前服务之后执行的命令

ExecReload：重启当前服务时执行的命令

ExecStop：停止当前服务时执行的命令

ExecStopPost：停止当其服务之后执行的命令

RestartSec：自动重启当前服务间隔的秒数

Restart：定义何种情况 Systemd 会自动重启当前服务，可能的值包括always（总是重启）、on-success、on-failure、on-abnormal、on-abort、on-watchdog

TimeoutSec：定义 Systemd 停止当前服务之前等待的秒数

Environment：指定环境变量

Target

启动计算机的时候，需要启动大量的Unit。如果每一次启动，都要一一写明本次启动需要哪些 Unit，显然非常不方便。Systemd 的解决方案就是 Target。

简单说，Target 就是一个 Unit 组，包含许多相关的 Unit 。启动某个 Target 的时候，Systemd 就会启动里面所有的 Unit。从这个意义上说，Target 这个概念类似于"状态点"，启动某个 Target 就好比启动到某种状态。

传统的init启动模式里面，有RunLevel的概念，跟Target的作用很类似。不同的是，RunLevel是互斥的，不可能多个RunLevel同时启动，但是多个Target可以同时启动。

# 查看当前系统的所有 Target

systemctl list-unit-files --type=target

# 查看一个 Target 包含的所有 Unit

systemctl list-dependencies multi-user.target

# 查看启动时的默认 Target

systemctl get-default

# 设置启动时的默认 Target

systemctl set-default multi-user.target

# 切换 Target 时，默认不关闭前一个 Target 启动的进程，

# systemctl isolate 命令改变这种行为，

# 关闭前一个 Target 里面所有不属于后一个 Target 的进程

systemctl isolate multi-user.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

它与init进程的主要差别如下。

（1）默认的 RunLevel（在/etc/inittab文件设置）现在被默认的 Target 取代，位置是/etc/systemd/system/default.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目录里面的修改可以覆盖原始设置。

日志管理

Systemd 统一管理所有 Unit 的启动日志。带来的好处就是，可以只用journalctl一个命令，查看所有日志（内核日志和应用日志）。日志的配置文件是/etc/systemd/journald.conf。

journalctl功能强大，用法非常多。

# 查看所有日志（默认情况下 ，只保存本次启动的日志）

journalctl

# 查看内核日志（不显示应用日志）

journalctl -k

# 查看系统本次启动的日志

journalctl -b

journalctl -b -0

# 查看上一次启动的日志（需更改设置）

journalctl -b -1

# 查看指定时间的日志

journalctl --since="2018-10-30 18:17:16"

journalctl --since "50 min ago"

journalctl --since yesterday

journalctl --since "2017-01-10" --until "2019-01-11 03:00"

journalctl --since 09:00 --until "3 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 nginx.service

journalctl -u nginx.service --since today

# 实时滚动显示某个 Unit 的最新日志

journalctl -u nginx.service -f

# 合并显示多个 Unit 的日志

journalctl -u nginx.service -u php-fpm.service --since today

# 查看指定优先级（及其以上级别）的日志，共有8级

# 0: emerg

# 1: alert

# 2: crit

# 3: err

# 4: warning

# 5: notice

# 6: info

# 7: debug

journalctl -p err -b

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

journalctl --no-pager

# 以 JSON 格式（单行）输出

journalctl -b -u nginx.service -o json

# 以 JSON 格式（多行）输出，可读性更好

journalctl -b -u nginx.serviceqq

-o json-pretty

# 显示日志占据的硬盘空间

journalctl --disk-usage

# 指定日志文件占据的最大空间

journalctl --vacuum-size=1G

journalctl --vacuum-time=1years