介绍
Systemd是一个初始系统和系统管理员，被广泛成为Linux机器的新标准。 虽然有关于是否可观的意见systemd是对传统的改进SysV初始化系统，它正在取代，多数分布计划采用它，或者已经这样做了。
由于其大量采用，熟悉自己与systemd是非常值得的麻烦，因为它会使行政的这些服务器要容易得多。 学习和利用构成的工具和守护程序systemd将帮助您更好地欣赏能力，灵活性和能力提供，或至少帮助您用最少的麻烦做你的工作。
在本指南中，我们将要讨论的systemctl命令，这是用于控制init系统的中央管理工具。 我们将介绍如何管理服务，检查状态，更改系统状态和使用配置文件。
服务管理
init系统的基本目的是初始化在Linux内核启动后必须启动的组件（传统上称为“用户级”组件）。 init系统还用于在系统运行时随时管理服务器的服务和守护进程。 考虑到这一点，我们将开始一些简单的服务管理操作。
在systemd ，大部分操作的目标是“单位”，这是资源systemd知道如何管理。 单位按照它们代表的资源类型进行分类，它们使用称为单元文件的文件进行定义。 每个单元的类型可以从文件末尾的Stapling推断。
对于服务管理任务，目标单位将服务单位，其中有一个Stapling单元文件.service 。 然而，对于大多数服务管理的命令，实际上你可以离开关.serviceStapling，如systemd是足够聪明，知道，你可能想用服务管理命令时对服务进行操作。
启动和停止服务
要启动systemd服务，执行在服务的单位文件的说明，使用start命令。 如果您正在运行作为一个非root用户，你将不得不使用sudo ，因为这会影响操作系统的状态：
sudo systemctl start application.service
正如我们上面提到的， systemd知道查找*.service为服务管理命令的文件，因此命令可以很容易地键入如下：
sudo systemctl start application
虽然你可以使用上面的格式一般行政，为清楚起见，我们将使用.serviceStapling为命令的其余部分是明确有关我们经营的目标。
要停止正在运行的服务，您可以使用stop命令：
sudo systemctl stop application.service
重新启动和重新加载
要重新启动正在运行的服务，您可以使用restart命令：
sudo systemctl restart application.service
如果有问题的应用程序能够重新加载其配置文件（无需重新启动），可以发出reload命令来启动该进程：
sudo systemctl reload application.service
如果您不确定服务是否有重新加载其配置的功能，您可以发出reload-or-restart命令。 这将在现场重新加载配置（如果可用）。 否则，它将重新启动服务，以便选择新配置：
sudo systemctl reload-or-restart application.service
启用和禁用服务
上述命令对于在当前会话期间启动或停止命令很有用。 告诉systemd在系统启动时自动启动的服务，则必须启用它们。
要在引导启动服务，使用enable命令：
sudo systemctl enable application.service
这将创建服务文件（通常在系统的副本的符号链接/lib/systemd/system或/etc/systemd/system ）到磁盘上的位置， systemd寻找自动启动文件（通常/etc/systemd/system/ some_target .target.wants ，我们要过去后的目标是在本指南中的）。
要禁止服务自动启动，您可以键入：
sudo systemctl disable application.service
这将删除指示应自动启动服务的符号链接。
请记住，启用服务不会在当前会话中启动它。 如果您要启动的服务，并在引导启用它，你将不得不发行同时start和enable命令。
检查服务的状态
要检查您的系统上的一个服务的状态，您可以使用status的命令：
systemctl status application.service
这将为您提供服务状态，cgroup层次结构和前几条日志行。
例如，当检查Nginx服务器的状态时，您可能会看到如下输出：
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago
Main PID: 495 (nginx)
CGroup: /system.slice/nginx.service
├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
└─496 nginx: worker process
Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server...
Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.
这将为您提供应用程序的当前状态的完整概述，通知您任何问题和可能需要的任何操作。
还有用于检查特定状态的方法。 例如，要检查是否一个单位是当前活动（运行），您可以使用is-active的命令：
systemctl is-active application.service
这将返回当前单元的状态，通常是active或inactive 。 如果激活，退出代码将为“0”，使得结果更容易编程解析。
要查看是否装置启用后，您可以使用is-enabled命令：
systemctl is-enabled application.service
这将输出服务是否被enabled或disabled ，并重新设置退出代码为“0”或“1”，根据答案的问题的命令。
第三个检查是单元是否处于故障状态。 这表示启动相关单元时出现问题：
systemctl is-failed application.service
这将返回active是否正确运行，或failed ，如果发生错误。 如果该单元被有意停止时，它可以返回unknown或inactive 。 退出状态“0”表示发生故障，退出状态“1”表示任何其他状态。
系统状态概述
到目前为止，这些命令对管理单个服务非常有用，但是它们对于探索系统的当前状态并不是很有帮助。 有许多的systemctl提供这样的信息的命令。
列出当前单位
要看到所有活动的单位名单systemd知道，我们可以使用list-units的命令：
systemctl list-units
这将显示你所有的单位名单systemd目前活跃在系统上。 输出将如下所示：
UNIT LOAD ACTIVE SUB DESCRIPTION
atd.service loaded active running ATD daemon
avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack
dbus.service loaded active running D-Bus System Message Bus
dcron.service loaded active running Periodic Command Scheduler
dkms.service loaded active exited Dynamic Kernel Modules System
getty@tty1.service loaded active running Getty on tty1
. . .
输出具有以下列：
- 单位 ：
systemd单位名称 - LOAD：无论设备的配置已经被解析
systemd。 加载单元的配置保存在内存中。 - ACTIVE：有关单位是否处于活动状态摘要状态。 这通常是一个相当基本的方法来判断单元是否已成功启动。
- SUB：这是一个较低级别的状态指示关于该单元的更详细的信息。 这通常随单元类型，状态和单元运行的实际方法而变化。
- 描述 ：单位为的简短文字说明/一样。
由于list-units命令在默认情况下只显示活跃的单位，所有上面的条目将显示在活动列在LOAD列“装”和“主动”。 该显示器实际上是默认行为systemctl时，无需额外的命令调用，所以你会看到同样的事情，如果你打电话systemctl不带参数：
systemctl
我们可以告诉systemctl通过添加额外的标志来输出不同的信息。 例如，要看到所有的单位systemd已加载（或试图加载），无论它们是否是当前活动，您可以使用--all标志，就像这样：
systemctl list-units --all
这将表明，任何单元systemd加载或试图加载，而不管其当前的状态的系统。 有的单位运行后变为无效，并且，一些单位systemd可能还没有在磁盘上发现试图加载。
您可以使用其他标志来过滤这些结果。 例如，我们可以使用--state=标志，以表明我们希望看到的负载，活动或SUB状态。 你将不得不保持--all标志，以便systemctl允许显示非活动的单位：
systemctl list-units --all --state=inactive
另一种常见的滤波器是--type=过滤器。 我们可以告诉systemctl到我们感兴趣的类型只显示单元例如，只查看有效的服务单位，我们可以使用：
systemctl list-units --type=service
列出所有单元文件
该list-units将只显示单元systemd试图解析并加载到内存中。 由于systemd将只读取它认为它需要的单位，这不一定会包括所有系统上的可用单位。 看到中的每一个可用的单元文件systemd路径，包括那些systemd并没有试图加载，你可以用list-unit-files的命令：
systemctl list-unit-files
单位是资源的表示systemd知道。 因为systemd并不一定读取所有的单元定义在此视图中，它仅显示有关文件本身的信息。 输出有两列：单元文件和状态。
UNIT FILE STATE
proc-sys-fs-binfmt_misc.automount static
dev-hugepages.mount static
dev-mqueue.mount static
proc-fs-nfsd.mount static
proc-sys-fs-binfmt_misc.mount static
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount static
var-lib-nfs-rpc_pipefs.mount static
org.cups.cupsd.path enabled
. . .
状态通常是“启用”，“禁用”，“静态”或“屏蔽”。 在本上下文中，static表示单元文件不包含用于启用单元的“安装”部分。 因此，无法启用这些单元。 通常，这意味着单元执行一次性动作或者仅用作另一个单元的依赖性，并且不应该由其自身运行。
我们将涵盖什么“掩蔽”意味着瞬间。
单位管理
到目前为止，我们一直在努力与服务，并显示有关该单元和单元文件信息systemd知道。 但是，我们可以使用一些附加命令找到有关单位的更多具体信息。
显示单元文件
要显示单元文件systemd已加载到其系统中，可以使用cat命令（在此加入systemd版本209）。 例如，看到的单元文件atd调度守护我们可以输入：
systemctl cat atd.service
[Unit]
Description=ATD daemon
[Service]
Type=forking
ExecStart=/usr/bin/atd
[Install]
WantedBy=multi-user.target
输出是作为已知的当前运行的单元文件systemd过程。 如果您最近修改了单元文件，或者您正在覆盖单元文件片段中的某些选项（这将在后面介绍），这可能很重要。
显示依赖关系
要查看设备的依赖关系树，你可以用list-dependencies命令：
systemctl list-dependencies sshd.service
这将显示一个层次结构，映射必须处理的依赖关系，以启动相关单元。 在本上下文中，依赖性包括那些上面的单元所需要的或者它们想要的单元。
sshd.service
├─system.slice
└─basic.target
├─microcode.service
├─rhel-autorelabel-mark.service
├─rhel-autorelabel.service
├─rhel-configure.service
├─rhel-dmesg.service
├─rhel-loadmodules.service
├─paths.target
├─slices.target
. . .
递归相关性仅显示.target单位，这表明系统状态。 递归地列出所有相关性，包括--all标志。
要显示反向依赖关系（单位依赖指定的单位），可以将添加--reverse标志的命令。 这是有用的其它标志是--before和--after标志，它可用于分别表示依赖开始之前指定单元上和后本身单位。
检查单位属性
要查看设备的低级别的属性，可以使用show命令。 这将显示正在使用的指定单位设置的属性列表key=value格式：
systemctl show sshd.service
Id=sshd.service
Names=sshd.service
Requires=basic.target
Wants=system.slice
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
Description=OpenSSH server daemon
. . .
如果你想显示单个属性，可以通过-p的属性名称标志。 例如，要看到冲突sshd.service单位有，您可以键入：
systemctl show sshd.service -p Conflicts
Conflicts=shutdown.target
屏蔽和取消屏蔽单位
我们的服务管理部分如何停止或禁用服务所看到的，但systemd还具有自动或手动标记机作为完全无法启动，通过其链接到的能力/dev/null 。 这就是所谓的掩蔽单元，并且可能用mask命令：
sudo systemctl mask nginx.service
这将防止Nginx服务自动或手动启动，只要它被屏蔽。
如果选中list-unit-files ，你会看到该服务现已被列为蒙面：
systemctl list-unit-files
. . .
kmod-static-nodes.service static
ldconfig.service static
mandb.service static
messagebus.service static
nginx.service masked
quotaon.service static
rc-local.service static
rdisc.service disabled
rescue.service static
. . .
如果您尝试启动服务，您将看到如下所示的消息：
sudo systemctl start nginx.service
Failed to start nginx.service: Unit nginx.service is masked.
要再次揭露一个单元，使其可以使用，只要使用unmask命令：
sudo systemctl unmask nginx.service
这将使单元返回到先前的状态，允许它被启动或启用。
编辑单位文件
虽然单元文件的具体格式是本教程的范围之外， systemctl提供了编辑和修改单元文件，如果你需要进行调整内建的机制。 在加入此功能systemd版本218。
该edit命令，默认情况下，将打开有问题的单位的单位文件片段：
sudo systemctl edit nginx.service
这将是一个空白文件，可用于覆盖或添加指令到单元定义。 目录将在中创建/etc/systemd/system其中包含了与单位的名称目录.d追加。 例如，对于nginx.service ，目录名为nginx.service.d将被创建。
在该目录中，一个片段将被创建名为override.conf 。 当本机装载， systemd将在内存中，合并与全单元文件覆盖片段。 代码段的指令将优先于原始单元文件中找到的指令。
如果您希望编辑，而不是创建一个片段完整的单元文件，你可以传递--full标志：
sudo systemctl edit --full nginx.service
这将加载当前单元文件到编辑器中，可以在其中进行修改。 当编辑器退出时，更改的文件将被写入/etc/systemd/system ，将优先于系统的自定义单位（通常是在某处发现/lib/systemd/system ）。
要删除您所做的任何添加，删除该设备的.d配置目录或从修改后的服务文件/etc/systemd/system 。 例如，要删除代码段，我们可以键入：
sudo rm -r /etc/systemd/system/nginx.service.d
要删除完整的修改单元文件，我们将键入：
sudo rm /etc/systemd/system/nginx.service
删除文件或目录后，你应该重新载入systemd过程，以便它不再试图引用这些文件，并恢复到使用系统副本。 您可以输入以下命令：
sudo systemctl daemon-reload
使用目标调整系统状态（运行级别）
目标是描述系统状态或同步点的特殊单元文件。 像其他的单位，定义目标的文件，可以通过它们的Stapling，而在这种情况下被识别.target 。 目标本身不做太多，而是用于将其他单元分组在一起。
这可以用于使系统达到某些状态，很像其他init系统使用运行级别。 它们用作某些功能可用时的参考，允许您指定所需的状态，而不是指定产生该状态所需的各个单位。
例如，有一种swap.target用来指示交换准备使用。 单位是这一进程的一部分可以通过指示在其配置中，他们与这个目标同步WantedBy=或RequiredBy=的swap.target 。 需要调剂可用单位可以指定这个条件使用Wants= ， Requires=和After=规格说明他们的关系的本质。
获取和设置默认目标
该systemd进程，它引导系统时使用一个默认的目标。 满足来自单个目标的依赖性级联将使系统进入期望的状态。 要查找系统的默认目标，请键入：
systemctl get-default
multi-user.target
如果你想设置不同的默认目标，则可以使用set-default 。 例如，如果您安装了一个图形桌面，并且希望系统默认启动它，您可以相应地更改默认目标：
sudo systemctl set-default graphical.target
列出可用的目标
您可以通过键入以下内容获取系统上的可用目标列表：
systemctl list-unit-files --type=target
与运行级别不同，多个目标可以同时处于活动状态。 活性目标指示systemd已试图启动所有绑在靶的单位，也没有试图再次撕裂下来。 要查看所有活动目标，请键入：
systemctl list-units --type=target
隔离目标
可以启动与目标相关联的所有单元，并停止不是从属树的一部分的所有单元。 我们需要做到这一点的命令被调用时，适当地， isolate 。 这类似于更改其他init系统中的运行级别。
举例来说，如果你是在一个图形化的环境中操作graphical.target活跃，您可以关闭图形化系统，把系统进入多用户的命令行状态下通过隔离multi-user.target 。 由于graphical.target取决于multi-user.target而不是倒过来，所有的图形单位将被停止。
您可能希望在执行此过程之前查看要隔离的目标的依赖关系，以确保您不会停止重要服务：
systemctl list-dependencies multi-user.target
当您对将要保持活动的单位感到满意时，可以通过键入以下内容来隔离目标：
sudo systemctl isolate multi-user.target
使用快捷方式进行重要事件
有重要事件定义的目标，如关闭电源或重新启动。 然而， systemctl也有一些快捷方式，加一点额外的功能。
例如，为了使系统进入救援（单用户）模式下，可以只使用rescue命令，而不是isolate rescue.target ：
sudo systemctl rescue
这将提供向所有已登录用户提醒有关事件的附加功能。
要停止系统，可以使用halt命令：
sudo systemctl halt
要启动完全关闭，您可以使用poweroff命令：
sudo systemctl poweroff
重新启动可与开始reboot命令：
sudo systemctl reboot
这些都警告用户记录事件发生，简单地运行或隔离目标不会做的事情。 需要注意的是，使他们与正常工作大部分机器将连接越短，更传统的命令进行这些操作systemd 。
例如，要重新引导系统，通常可以键入：
sudo reboot
结论
现在，你应该熟悉一些基本功能systemctl ，让您互动和控制您的命令systemd实例。 该systemctl工具将是您的服务和系统状态管理交互要点。
而systemctl主要操作与芯systemd过程中，有其它组分的systemd由其他公用事业控制生态系统。 其他功能，例如日志管理和用户会话由单独的守护程序和管理工具（处理journald / journalctl和logind / loginctl分别）。 花时间熟悉这些其他工具和守护进程将使管理变得更容易。
