CentOS7/RHEL7 systemd详解

CentOS7/RHEL7 systemd详解

目录
1. 为何是systemd
（1） 关于Linux服务管理
（2） SysV init的优缺点
（3） UpStart的改进
（4） systemd的诞生
（5）为何systemd能作到启动很快
2. SysV init介绍
（1） 什么是SystemV
（2）SysV init的运行级别
（3）SysV init运行顺序
（4）SysV init和系统关闭
（5）SysV init的管理和控制功能
3. systemd的特性
（1）systemd解决了那些问题？
（2）systemd的争议在哪里？
（3）systemd能更完全的结束服务进程
4. CentOS 7的systemd特性
（1）套接字服务保持激活功能
（2）进程间通信保持激活功能
（3）设备保持激活功能
（4）文件路径保持激活功能
（5）系统状态快照
（6）挂载和自动挂载点管理
（7）闪电并行启动
（8）单元逻辑模拟检查
（9）和SysV init向后兼容
5. 如何分析衡量systemd启动速度
（1）查看详细的每一个服务消耗的启动时间
（2）查看严重消耗时间的服务树状表
（3）打印分析图及其余命令
6. CentOS 7的systemd向后兼容
（1）systemd对运行级别支持有限。
（2）systemd不支持像init脚本那样的个性化命令。
（3）systemd不支持和没有从systemd启动的服务通信。
（4）systemd能够只中止运行的服务
（5）不能从标准输出设备读到系统服务信息。
（6）systemd不继承任何上下文环境。
（7）SysV init脚本依赖性
（8）超时机制
7. systemd服务管理
（1） 什么是单元
（2）systemd的服务管理
（3）服务详细信息查看
8. 使用systemd target
（1）怎样知道一个目标须要哪些进程服务？
（2）target与运行级别
（3）target管理
9. 关闭、暂停、休眠系统
10. 经过systemd管理远程系统
11. 建立和修改systemd单元文件
（1）单元文件概述
（2）理解单元文件结构
（3）建立自定义的单元文件
（4）建立emacs.service例子：
（5）建立第二个sshd服务的例子
（6）修改已经存在的单元文件
（7）扩展默认单元配置文件配置
12. 单元实例化
13. VNC SERVER配置


1.为何是systemd

（1） 关于Linux服务管理

Linux系统从启动到提供服务的过程是这样，先是机器加电，而后经过MBR或者UEFI加载GRUB，再启动内核，内核启动服务，而后开始对外服务。
SysV init UpStart systemd主要是解决服务引导管理的问题。
提示：关于systemd的拼写，官方的说法就是systemd，既不是Syetemd，也是不systemD。

（2） SysV init的优缺点

SysV init是最先的解决方案，依靠划分不一样的运行级别，启动不一样的服务集，服务依靠脚本控制，而且是顺序执行的。
SysV init方案的优势是：
原理简单，易于理解；
依靠shell脚本控制，编写服务脚本门槛比较低。
缺点是：
服务顺序启动，启动过程比较慢；
不能作到根据须要来启动服务，好比一般但愿插入U盘的时候，再启动USB控制的服务，这样能够更好的节省系统资源。

（3） UpStart的改进

为了解决系统服务的即插即用，UpStart应运而生，在CentOS6系统中，SysV init和UpStart是并存的，UpStart主要解决了服务的即插即用。服务顺序启动慢的问题，UpStart的解决办法是把相关的服务分组，组内的服务是顺序启动，组之间是并行启动。

（4） systemd的诞生

SysV init服务启动慢，在之前并非一个问题，尤为是Linux系统之前主要是在服务器系统上，常年也可贵重启一次。有的服务器光硬件检测都须要5分钟以上，相对来讲系统启动已经很快了。
可是随着移动互联网的到来，SysV init服务启动慢的问题显得愈来愈突出，许多移动设备都是基于Linux内核，好比安卓。移动设备启动比较频繁，每次启动都要等待服务顺序启动，显然难以接受，systemd就是为了解决这个问题诞生的。
systemd的设计思路是：
尽量的快速启动服务；
尽量的减小系统资源占用。

（5）为何systemd能作到启动很快

systemd使用并行的方法启动服务，不像SysV init是顺序执行的，因此大大节省了系统启动时间。
使用并行启动，最大的难点是要解决服务之间的依赖性，systemd的解决办法是使用相似缓冲池的办法。好比对TCP有依赖的服务，在启动的时候会检查依赖服务的TCP端口，systemd会把对TCP端口的请求先缓存起来，当依赖的服务器启动以后，在将请求传递给服务，使两个服务通信。一样的进程间通信的D-BUS也是这样的原理，目录挂载则是先让服务觉得目录被挂载了，到真正访问目录的时候，才去真正操做。

2.SysV init介绍

SysV init是systemV风格的init系统，顾名思义，它源于SystemV系列UNIX。它提供了比BSD风格init系统更高的灵活性。是已经风行了几十年的UNIX init系统，一直被各种Linux发行版所采用。

（1） 什么是SystemV

SystemV，曾经也被称为AT&T SystemV，是Unix操做系统众多版本中的一支。它最初由AT&T开发，在1983年第一次发布。一共发行了4个SystemV的主要版本：版本一、二、3和4。SystemV Release4，或者称为SVR4，是最成功的版本，成为一些UNIX共同特性的源头，例如”SysV初始化脚本“（/etc/init.d），用来控制系统启动和关闭，SystemV Interface Definition(SVID)是一个SystemV如何工做的标准定义。

（2）SysV init的运行级别

SysV init用术语runlevel来定义"预订的运行模式"。SysV init检查'/etc/inittab'文件中是否含有'initdefault'项。来告诉init系统是否有一个默认运行模式。若是没有默认的运行模式，那么用户将进入系统控制台，手动决定进入何种运行模式。
SysV init中运行模式描述了系统各类预订的运行模式。一般会有8种运行模式，即运行模式0到6和S或者s。
每种Linux发行版对运行模式的定义都不太同样。但0，1，6却获得了你们的一致赞同：
0关机
1单用户模式
6重启
一般在/etc/inittab文件中定义了各类运行模式的工做范围。好比RedHat定义了runlevel3和5。运行模式3将系统初始化为字符界面的shell模式；运行模式5将系统初始化为GUI模式。不管是命令行界面仍是GUI，运行模式3和5相对于其余运行模式而言都是完整的正式的运行状态，计算机能够完成用户须要的任务。而模式1，S等每每用于系统故障以后的排错和恢复。
很显然，这些不一样的运行模式下系统须要初始化运行的进程，须要进行的初始化准备都是不一样的。好比运行模式3不须要启动X系统。用户只须要指定须要进入哪一种模式，SysV init负责执行全部该模式所必须的初始化工做。

（3）SysV init运行顺序

SysV init巧妙地用脚本，文件命名规则和软连接来实现不一样的runlevel。首先，SysV init须要读取/etc/inittab文件。分析这个文件的内容，它得到如下一些配置信息：
系统须要进入的runlevel；
捕获组合键的定义；
定义电源fail/restore脚本；
启动getty和虚拟控制台；
获得配置信息后，SysV init顺序地执行如下这些步骤，从而将系统初始化为预订的runlevelX：
/etc/rc.d/rc.sysinit
/etc/rc.d/rc和/etc/rc.d/rcX.d/(X表明运行级别0-6)
/etc/rc.d/rc.local
XDisplayManager（若是须要的话）

1）rc.sysinit脚本功能

首先，运行rc.sysinit以便执行一些重要的系统初始化任务。在RedHat公司的RHEL5中(RHEL6已经使用UpStart了)，rc.sysinit主要完成如下这些工做：
激活udev和selinux；
设置定义在/etc/sysctl.conf中的内核参数；
设置系统时钟；
加载keymaps；
激活交换分区；
设置主机名(hostname)；
根分区检查和remount；
激活RAID和LVM设备；
开启磁盘配额；
检查并挂载全部文件系统；
清除过时的locks和PID文件；

2）rc.d脚本

完成了以上这些工做以后，SysV init开始运行/etc/rc.d/rc脚本。根据不一样的runlevel，rc脚本将打开对应runlevel的rcX.d目录(X就是runlevel)，找到并运行存放在该目录下的全部启动脚本。每一个runlevelX都有一个这样的目录，目录名为/etc/rc.d/rcX.d。
在这些目录下存放着不少不一样的脚本。文件名以S开头的脚本就是启动时应该运行的脚本，S后面跟的数字定义了这些脚本的执行顺序。在/etc/rc.d/rcX.d目录下的脚本其实都是一些软连接文件，真实的脚本文件存放在/etc/init.d目录下。以下所示：
rc5.d目录下的脚本

[root@www~]#ll/etc/rc5.d/
lrwxrwxrwx1rootroot16Sep42008K02dhcdbd->../init.d/dhcdbd
....(中间省略)....
lrwxrwxrwx1rootroot14Sep42008K91capi->../init.d/capi
lrwxrwxrwx1rootroot23Sep42008S00microcode_ctl->../init.d/microcode_ctl
lrwxrwxrwx1rootroot22Sep42008S02lvm2-monitor->../init.d/lvm2-monitor
....(中间省略)....
lrwxrwxrwx1rootroot17Sep42008S10network->../init.d/network
....(中间省略)....
lrwxrwxrwx1rootroot11Sep42008S99local->../rc.local
lrwxrwxrwx1rootroot16Sep42008S99smartd->../init.d/smartd
....(底下省略)....

当全部的初始化脚本执行完毕。SysV init运行/etc/rc.d/rc.local脚本。
rc.local是Linux留给用户进行个性化设置的地方。能够把本身私人想设置和启动的东西放到这里，一台LinuxServer的用户通常不止一个，因此才有这样的考虑。

（4）SysV init和系统关闭

SysV init不只须要负责初始化系统，还须要负责关闭系统。在系统关闭时，为了保证数据的一致性，须要当心地按顺序进行结束和清理工做。
好比应该先中止对文件系统有读写操做的服务，而后再umount文件系统。不然数据就会丢失。
这种顺序的控制这也是依靠/etc/rc.d/rcX.d/目录下全部脚本的命名规则来控制的，在该目录下全部以K开头的脚本都将在关闭系统时调用，字母K以后的数字定义了它们的执行顺序。
这些脚本负责安全地中止服务或者其余的关闭工做。

（5）SysV init的管理和控制功能

此外，在系统启动以后，管理员还须要对已经启动的进程进行管理和控制。SysV init软件包包含了一系列的控制启动，运行和关闭全部其余程序的工具。
halt中止系统。
init就是SysV init自己的init进程实体，以pid1身份运行，是全部用户进程的父进程。最主要的做用是在启动过程当中使用/etc/inittab文件建立进程。
killall5就是System V的killall命令。向除本身的会话(session)进程以外的其它进程发出信号，因此不能杀死当前使用的shell。
last回溯/var/log/wtmp文件(或者-f选项指定的文件)，显示自从这个文件创建以来，全部用户的登陆状况。
lastb做用和last差很少，默认状况下使用/var/log/btmp文件，显示全部失败登陆企图。
mesg控制其它用户对用户终端的访问。
pidof找出程序的进程识别号(pid)，输出到标准输出设备。
poweroff等于shutdown-h–p，或者telinit0。关闭系统并切断电源。
reboot等于shutdown–r或者telinit6。重启系统。
runlevel读取系统的登陆记录文件(通常是/var/run/utmp)把之前和当前的系统运行级输出到标准输出设备。
shutdown以一种安全的方式终止系统，全部正在登陆的用户都会收到系统将要终止通知，而且不许新的登陆。
sulogin当系统进入单用户模式时，被init调用。当接收到启动加载程序传递的-b选项时，init也会调用sulogin。
telinit实际是init的一个链接，用来向init传送单字符参数和信号。
utmpdump以一种用户友好的格式向标准输出设备显示/var/run/utmp文件的内容。
wall向全部有信息权限的登陆用户发送消息。
不一样的Linux发行版在这些SysV init的基本工具基础上又开发了一些辅助工具用来简化init系统的管理工做。好比RedHat的RHEL在SysV init的基础上开发了initscripts软件包，包含了大量的启动脚本(如rc.sysinit)，还提供了service，chkconfig等命令行工具，甚至一套图形化界面来管理init系统。其余的Linux发行版也有各自的initscript或其余名字的init软件包来简化SysV init的管理。
只要理解了SysV init的机制，在一个最简的仅有SysV init的系统下，能够直接调用脚本启动和中止服务，手动建立inittab和建立软链接来完成这些任务。所以理解SysV init的基本原理和命令是最重要的。甚至也能够开发本身的一套管理工具。

3.systemd的特性

（1）systemd解决了那些问题？

按需启动服务，减小系统资源消耗；
尽量并行启动进程，减小系统启动等待时间；
提供一个一致的配置环境，不光是服务配置；
提供服务状态快照，能够恢复特定点的服务状态。

（2）systemd的争议在哪里？

systemd试图提供一个一致的配置环境，请注意不光是服务配置，还包括其余方面的系统配置，这个也是systemd的野心，但愿能把Linux系统上的配置统一块儿来，为了达到这个目标，systemd牺牲掉了SysV init和BSD系统的兼容性。systemd充分利用了Linux内核API，不在支持BSD系统，这个是systemd目前在开源社区最大的争论。
我的人为这个是个好事情，对管理员来说，不再用学习不一样发行版上不一样的配置，也不用为了写一个脚本，先去写一堆判断，判断不一样的发型版。运维自动化的前提是标准化，只有标准化了，才能自动化，systemd朝这个方向走了一大步。即便systemd的学习成本比较高。

（3）systemd能更完全的结束服务进程

服务(daemon)进程，为了成为服务，会fork两次，因此进程编号会发生变化，UpStart在结束进程的时候，有可能会找错进程编号，形成服务永远不被中止。
还有更特殊的状况，若是进程产生了子进程，子进程又本身fork了两次，脱离了主进程，要结束这样的子进程，UpStart的办法是经过strace追踪fork，exit调用，这种方法很是复杂。
systemd利用了内核最新的特性，使用CGroup解决这个问题，CGroup的进程是树状的，所以不管服务如何启动新的子进程，全部的这些相关进程都会属于同一个CGroup，systemd只须要简单地遍历指定的CGroup便可正确地找到全部的相关进程，将它们一一中止便可。

4.CentOS 7的systemd特性

（1）套接字服务保持激活功能

在系统启动的时候，systemd为全部支持套接字激活功能的服务建立监听端口，当服务启动后，就将套接字传给这些服务。这种方式不只能够容许服务在启动的时候平行启动，也能够保证在服务重启期间，试图链接服务的请求，不会丢失。对服务端口的请求被保留，而且存放到队列中。

（2）进程间通信保持激活功能

当有客户端应用第一次经过D-Bus方式请求进程间通信时，systemd会当即启动对应的服务。systemd依据D-Bus的配置文件使用进程间通信保持激活功能。

（3）设备保持激活功能

当特定的硬件插入时，systemd启动对应的硬件服务支持。systemd依据硬件服务单元配置文件保持硬件随时被激活。

（4）文件路径保持激活功能

当特定的文件或者路径状态发生改变的时候，systemd会激活对应的服务。systemd依据路径服务单元配置文件保证服务被激活。

（5）系统状态快照

systemd能够临时保存当前全部的单元配置文件，或者从前一个快照中恢复单元配置文件。为了保存当前系统服务状态，systemd能够动态的生成单元文件快照。

（6）挂载和自动挂载点管理

systemd监控和管理挂载和自动挂载点，并根据挂载点的单元配置文件进行挂载。

（7）闪电并行启动

由于使用套接字保持激活功能，systemd能够并行的启动因此套接字监听服务，大大减小系统启动时间。

（8）单元逻辑模拟检查

当激活或者关闭一个单元，systemd会计算依赖行，产生一个临时的模拟检查，而且校验一直性。若是不一致，systemd会尝试自动修正，而且移除报错的不重要的任务。

（9）和SysV init向后兼容

systemd彻底支持SysV initLinux标准的基础核心规范脚本，这样的脚本易于升级到systemd服务单元。

5.如何分析衡量systemd启动速度

systemd-analyze是一个分析启动性能的工具，用于分析启动时服务时间消耗。默认显示启动是内核和用户空间的消耗时间：

[root@localhost~]#systemd-analyze
Startupfinishedin818ms(kernel)+6.240s(initrd)+32.979s(userspace)=40.038s

和使用systemd-analyzetime命令的效果同样。

（1）查看详细的每一个服务消耗的启动时间

经过systemd-analyzeblame命令查看详细的每一个服务消耗的启动时间：

[root@localhost~]#systemd-analyzeblame
30.852siscsi.service
16.994skdump.service
10.871sboot.mount
...
103mssystemd-sysctl.service
101msdatapool.mount

（2）查看严重消耗时间的服务树状表

systemd-analyzecritical-chain命令打印严重消耗时间的服务树状表，按照启动消耗的时间进行排序，时间消耗越多，越排到前面。@以后是服务激活或者启动的时间，+号以后是服务启动消耗的时间。我的理解@是从系统引导到服务启动起来的时间，是一个相对时间消耗，+是服务启动消耗的时间，是一个绝对时间消耗。

[root@localhost~]#systemd-analyzecritical-chain
Thetimeaftertheunitisactiveorstartedisprintedafterthe"@"character.
Thetimetheunittakestostartisprintedafterthe"+"character.
multi-user.target@32.976s
└─kdump.service@15.981s+16.994s
└─network.target@15.980s
└─NetworkManager.service@15.069s+54ms
└─firewalld.service@14.532s+535ms
└─basic.target@14.532s
└─sockets.target@14.532s
└─dbus.socket@14.532s
└─sysinit.target@14.527s
└─systemd-update-utmp.service@14.524s+2ms
└─systemd-tmpfiles-setup.service@14.456s+67ms
└─local-fs.target@14.447s
└─boot.mount@3.575s+10.871s
└─systemd-fsck@dev-disk-by\x2duuid-8c77568b\x2d7e51\x2d4e32\x2dbbdf\x2ddc12ff737bbf.service@3.348s+226ms
└─systemd-fsck-root.service@1.237s+152ms
└─systemd-readahead-replay.service@1.073s+25ms

（3）打印分析图及其余命令

systemd-analyzeplot打印一个svg格式的服务消耗时间表，经过浏览器能够以图形的方式展现，很是直观：

[root@localhost~]#systemd-analyzeplot>plot.svg

其余参数：
systemd-analyzedot用分隔符产生当前服务
systemd-analyzedump以友好方式显示当前服务状态
6systemd文件类型及存放位置
systemd配置文件被称为unit单元，根据类型不一样，以不一样的扩展名结尾。
.service系统服务；
.target一组系统服务；
.automount自动挂载点；
.device能被内核识别的设备；
.mount挂载点；
.path文件系统的文件或者目录；
.scope外部建立的进程；
.slice一组分层次管理的系统进程；
.snapshot系统服务状态管理；
.socket进程间通信套接字；
.swap定义swap文件或者设备；
.timer定义定时器。

6.CentOS 7的systemd向后兼容

systemd被设计成尽量向后兼容SysV init和Upstart，下面是一些特别要注意的和以前主要版本的RHEL再也不兼容的部分。

（1）systemd对运行级别支持有限。

为了保存兼容，systemd提供必定数量的target单元，能够直接和运行级别对应，也能够被早期的分布式的运行级别命令支持。不是全部的target均可以被映射到运行级别，在这种状况下，使用runlevel命令有可能会返回一个为N的不知道的运行级别，因此推荐尽可能避免在RHEL7中使用runlevel命令。

（2）systemd不支持像init脚本那样的个性化命令。

除了一些标准命令参数例如：start、stop、status，SysV init脚本能够根据须要支持想要的任何参数，经过参数提供附加的功能，由于SysV init的服务器脚本实际上就是shell脚本，命令参数实际上就是shell子函数。举个例子，RHEL6的iptables服务脚本能够执行panic命令行参数，这个参数可让系统当即进入紧急模式，丢弃全部的进入和发出的数据包。可是相似这样的命令行参数在systemd中是不支持的，systemd只支持在配置文件中指定命令行参数。

（3）systemd不支持和没有从systemd启动的服务通信。

当systemd启动服务的时候，他保存进程的主ID以便于追踪，systemctl工具使用进程PID查询和管理服务。相反的，若是用户从命令行启动特定的服务，systemctl命令是没有办法判断这个服务的状态是启动仍是运行的。

（4）systemd能够只中止运行的服务

在RHEL6及以前的版本，当关闭系统的程序启动以后，RHEL6的系统会执行/etc/rc0.d/下全部服务脚本的关闭操做，无论服务是处于运行或者根本没有运行的状态。而systemd能够作到只关闭在运行的服务，这样能够大大节省关机的时间。

（5）不能从标准输出设备读到系统服务信息。

systemd启动服务的时候，将标准输出信息定向到/dev/null，以避免打扰用户。

（6）systemd不继承任何上下文环境。

systemd不继承任何上下文环境，如用户或者会话的HOME或者PATH的环境变量。每一个服务获得的是干净的上下文环境。

（7）SysV init脚本依赖性

当systemd启动SysV init脚本，systemd在运行的时候，从LinuxStandardBase(LSB)Linux标准库头文件读取服务的依赖信息并继承。

（8）超时机制

为了防止系统被卡住，全部的服务有5分钟的超时机制。

7.systemd服务管理

（1） 什么是单元

在RHEL7以前，服务管理是分布式的被SysV init或UpStart经过/etc/rc.d/init.d下的脚本管理。这些脚本是经典的Bash脚本，容许管理员控制服务的状态。在RHEL7中，这些脚本被服务单元文件替换。
在systemd中，服务、挂载等资源统一被称为单元，因此systemd中有许多单元类型，服务单元文件的扩展名是.service，同脚本的功能类似。例若有查看、启动、中止、重启、启用或者禁止服务的参数。
systemd单元文件放置位置：
/usr/lib/systemd/system/systemd默认单元文件安装目录
/run/systemd/systemsystemdsystemd单元运行时建立，这个目录优先于按照目录
/etc/systemd/system系统管理员建立和管理的单元目录，优先级最高。

（2）systemd的服务管理

使用systemcl命令能够控制服务，service命令和chkconfig命令依然可使用，可是主要是出于兼容的缘由，应该尽可能避免使用。
使用systemctl命令的时候，服务名字的扩展名能够写全，例如：
systemctl stop bluuetooth.service
也能够忽略，例如：
systemctl stop bluetooth
systemctl经常使用命令：
启动服务 systemctl start name.service
关闭服务 systemctl stop name.service
重启服务 systemctl restar tname.service
仅当服务运行的时候，重启服务 systemctl try-restart name.service
从新加载服务配置文件 systemctl relaod name.service
检查服务运做状态 systemctl status name.service 或者 systemctl is-active\ name.service
展现全部服务状态详细信息 systemctl list-units--type service --all
容许服务开机启动 systemctl enable name.service
禁止服务开机启动 systemclt disable name.service
检查服务开机启动状态 systemctl status name.service 或者systemctl\
is-enabled name.service
列出全部服务而且检查是否开机启动 systemctl list-unit-files --type service

（3）服务详细信息查看

使用以下命令列出服务：
systemctl list-units --type service
默认只列出处于激活状态的服务，若是但愿看到全部的服务，使用--all或-a参数：
systemctl list-units--type service --all
有时候但愿看到因此能够设置开机启动的服务，使用以下命令：
systemctl list-unit-files --type service
查看服务详细信息，使用以下命令：
systemctl status name.service
服务信息关键词解释
Loaded服务已经被加载，显示单元文件绝对路径，标志单元文件可用。
Active服务已经被运行，而且有启动时间信息。
Main PID与进程名字一致的PID，主进程PID。
Status服务的附件信息。
Process相关进程的附件信息。
CGroup进程的CGroup信息。

8.使用systemd target

（1）怎样知道一个目标须要哪些进程服务？

例如，可能想搞明白目标单元multi-user.target究竟启用了哪些服务，使用如下命令：

$systemctlshow-p"Wants"multi-user.target
Wants=rc-local.serviceavahi-daemon.servicerpcbind.serviceNetworkManager.serviceacpid.servicedbus.serviceatd.servicecrond.serviceauditd.servicentpd.serviceudisks.servicebluetooth.serviceorg.cups.cupsd.servicewpa_supplicant.servicegetty.targetmodem-manager.serviceportreserve.serviceabrtd.serviceyum-updatesd.serviceupowerd.servicetest-first.servicepcscd.servicersyslog.servicehaldaemon.serviceremote-fs.targetplymouth-quit.servicesystemd-update-utmp-runlevel.servicesendmail.servicelvm2-monitor.servicecpuspeed.serviceudev-post.servicemdmonitor.serviceiscsid.servicelivesys.servicelivesys-late.serviceirqbalance.serviceiscsi.service

除了Wants，还能够查看各类形式的依赖和被依赖信息：WantedBy、Requires、RequiredBy、Conflicts、ConflictedBy、Before、After。

（2）target与运行级别

在RHEL7以前的版本，使用运行级别表明特定的操做模式。运行级别被定义为七个级别，用数字0到6表示，每一个级别能够启动特定的一些服务。RHEL7使用target替换运行基本。
systemd target使用target单元文件描述，target单位文件扩展名是.target，target单元文件的惟一目标是将其余systemd单元文件经过一连串的依赖关系组织在一块儿。举个例子，graphical.target单元，用于启动一个图形会话，systemd会启动像GNOME显示管理(gdm.service)、账号服务（axxounts-daemon）这样的服务，而且会激活multi-user.target单元。类似的multi-user.target单元，会启动必不可少的NetworkManager.service、dbus.service服务，并激活basic.target单元。
RHEL7预约义了一些target和以前的运行级别或多或少有些不一样。为了兼容，systemd也提供一些target映射为SysV init的运行级别，具体的对应信息以下：
0runlevel0.target,poweroff.target关闭系统。
1runlevel1.target,rescue.target进入救援模式。
2runlevel2.target,multi-user.target进入非图形界面的多用户方式。
3runlevel3.target,multi-user.target进入非图形界面的多用户方式。
4runlevel4.target,multi-user.target进入非图形界面的多用户方式。
5runlevel5.target,graphical.target进入图形界面的多用户方式。
6runlevel6.target,reboot.target重启系统。

（3）target管理

1）使用以下命令查看目前可用的target：

systemctl list-units --type target

改变当前的运行基本使用以下命令：

systemctl isolate name.target

2）修改默认的运行级别
使用systemctl get-default命令获得默认的运行级别：

[root@localhost~]#systemctlget-default
multi-user.target

使用systemctl set-default name.target修改默认的运行基本

[root@localhost~]#systemctlset-defaultgraphical.target
rm'/etc/systemd/system/default.target'
ln-s'/usr/lib/systemd/system/graphical.target''/etc/systemd/system/default.target'

3）救援模式和紧急模式
使用systemctl rescue进入救援模式，若是连救援模式都进入不了，能够进入紧急模式：

systtmctl emergency

紧急模式进入作小的系统环境，以便于修复系统。紧急模式根目录以只读方式挂载，不激活网络，只启动不多的服务，进入紧急模式须要root密码。

9.关闭、暂停、休眠系统

RHEL7中，使用systemctl替换一些列的电源管理命令，原有的命令依旧可使用，可是建议尽可能不用使用。systemctl和这些命令的对应关系为：
hatl，systemctl halt中止系统
poweroff，systemctl poweroff关闭系统，关闭系统电源。
reboot，systemctl reboot重启系统
pm-suspend，systemctl suspend暂停系统
pm-hibernate，systemct lhibernate休眠系统
pm-suspend-hybrid，systemctl hybrid-sleep暂停并休眠系统

10.经过systemd管理远程系统

不光是能够管理本地系统，systemd还能够控制远程系统，管理远程系统主要是经过SSH协议，只有确承认以链接远程系统的SSH，在systemctl命令后面添加-H或者--host参数，加上远程系统的ip或者主机名就能够。

11.建立和修改systemd单元文件

（1）单元文件概述

单元文件包含单元的指令和行为信息。在后台systemctl命令和单元文件一块儿工做。为了出色而正确的完成工做，系统管理员必须可以手工编辑单元文件。通常系统管理员手工建立的单元文件建议存放在/etc/systemd/system/目录下面。
单元配置文件的格式是：

unit_name.type_extension

这里的unit_name表明单元名称，type_extension表明单元类型。
单元文件能够做为附加的文件放置到一个目录下面，好比为了定制sshd.service服务，能够建立sshd.service.d/custom.conf文件，在文件中作一些自定义的配置。
一样的，能够建立sshd.service.wants/和sshd.service.requires/目录。这些目录包含sshd服务关联服务的软链接，在系统安装的时候，这些软链接或自动建立，也能够手工建立软链接。
许多单元配置文件可使用单元说明符--通配的字符串，能够在单元文件被引导的时候动态的被变量替换。这使建立一些通用的单元配置模版成为可能。

（2）理解单元文件结构

典型的单元文件包含三节：
[Unit]节，包含不依赖单元类型的通常选项，这些选型提供单元描述，知道单元行为，配置单元和其余单元的依赖性。
[unittype]节，若是单元有特定的类型指令，在unittype节这些指令被组织在一块儿。举个例子，服务单元文件包含[Service]节，里面有常用的服务配置。
[Install]节，包含systemctlenable或者disable的命令安装信息。
1）[Unit]节选项
Description单元描述信息，这些文字信息在systemclstatus命令是会输出。
Documentation单元文档信息的URLs。
After定义在那些单元以后启动，本单元只在制定的单元启动以后启动，不像Requires选项，After选项不明确激活特定的单元，Before选项则是有相反的功能。
Requires配置单元的依赖性，在Requires选项中的单元须要一块儿被激活，若是有一个单元启动失败，其余单元都不会被启动。
Wants比Requires选项依赖性要弱不少，若是列表之中的的单元启动失败，不会对其余单元形成影响，这是推荐的创建自定义单元依赖性的方式。
Conflicts定义单元冲突关系，和Requires相反。
2）[unittype]类型是[Service]时的选项
Type配置单元进程在启动时候的类型，影响执行和关联选项的功能，可选的关键字是：
simple默认值，进程和服务的主进程一块儿启动；
forking进程做为服务主进程的一个子进程启动，父进程在彻底启动以后退出。
oneshot同simple类似，可是进程在启动单元以后随之退出。
dbus同simple类似，可是随着单元启动后只有主进程获得D-BUS名字。
notify同simple类似，可是随着单元启动以后，一个主要信息被sd_notify()函数送出。
idle同simple类似，实际执行进程的二进制程序会被延缓直到全部的单元的任务完成，主要是避免服务状态和shell混合输出。
ExecStart指定启动单元的命令或者脚本，ExecStartPre和ExecStartPost节指定在ExecStart以前或者以后用户自定义执行的脚本。Type=oneshot容许指定多个但愿顺序执行的用户自定义命令。
ExecStop指定单元中止时执行的命令或者脚本。
ExecReload指定单元从新加载是执行的命令或者脚本。
Restart这个选项若是被容许，服务重启的时候进程会退出，会经过systemctl命令执行清除并重启的操做。
RemainAfterExit若是设置这个选择为真，服务会被认为是在激活状态，即便因此的进程已经退出，默认的值为假，这个选项只有在Type=oneshot时须要被配置。
3）[Install]节选项
Alias为单元提供一个空间分离的附加名字。
RequiredBy单元被容许运行须要的一系列依赖单元，RequiredBy列表从Require得到依赖信息。
WantBy单元被容许运行须要的弱依赖性单元，Wantby从Want列表得到依赖信息。
Also指出和单元一块儿安装或者被协助的单元。
DefaultInstance实例单元的限制，这个选项指定若是单元被容许运行默认的实例。
4）一个postfix服务的例子：
单元文件位于/usr/lib/systemd/system/postifix.service，内容以下：

[Unit]
Description=PostfixMailTransportAgent
After=syslog.targetnetwork.target
Conflicts=sendmail.serviceexim.service
[Service]
Type=forking
PIDFile=/var/spool/postfix/pid/master.pid
EnvironmentFile=-/etc/sysconfig/network
ExecStartPre=-/usr/libexec/postfix/aliasesdb
ExecStartPre=-/usr/libexec/postfix/chroot-update
ExecStart=/usr/sbin/postfixstart
ExecReload=/usr/sbin/postfixreload
ExecStop=/usr/sbin/postfixstop
[Install]
WantedBy=multi-user.target

（3）建立自定义的单元文件

如下几种场景须要自定义单元文件：
但愿本身建立守护进程；
为现有的服务建立第二个实例；
引入SysV init脚本。
另一方面，有时候须要修改已有的单元文件。
下面介绍建立单元文件的步骤：
1）准备自定义服务的执行文件。
可执行文件能够是脚本，也能够是软件提供者的的程序，若是须要，为自定义服务的主进程准备一个PID文件，一保证PID保持不变。另外还可能须要的配置环境变量的脚本，确保因此脚本都有可执行属性而且不须要交互。
2）在/etc/systemd/system/目录建立单元文件，而且保证只能被root用户编辑：

touch/etc/systemd/system/name.servicechmod664/etc/systemd/system/name.service

文件不须要执行权限。
3）打开name.service文件，添加服务配置，各类变量如何配置视所添加的服务类型而定，下面是一个依赖网络服务的配置例子：

[Unit]
Description=service_description
After=network.target
[Service]
ExecStart=path_to_executable
Type=forking
PIDFile=path_to_pidfile
[Install]
WantedBy=default.target

4）通知systemd有个新服务添加：

systemctldaemon-reload
systemctlstartname.service

（4）建立emacs.service例子：

1）建立文件，并确保正确权限：

~]#touch/etc/systemd/system/emacs.service
~]#chmod664/etc/systemd/system/emacs.service

2）添加配置信息：

[Unit]
Description=Emacs:theextensible,self-documentingtexteditor
[Service]
Type=forking
ExecStart=/usr/bin/emacs--daemon
ExecStop=/usr/bin/emacsclient--eval"(kill-emacs)"
Environment=SSH_AUTH_SOCK=%t/keyring/ssh
Restart=always
[Install]
WantedBy=default.target

3）通知systemd并开启服务：

~]#systemctldaemon-reload
~]#systemctlstartemacs.service

（5）建立第二个sshd服务的例子

1）拷贝sshd_config文件

]#cp/etc/ssh/sshd{,-second}_config

2）编辑sshd-second_config文件，添加22220的端口，和PID文件：

Port22220
PidFile/var/run/sshd-second.pid

若是还须要修改其余参数，请阅读帮助。
3）拷贝单元文件：

~]#cp/usr/lib/systemd/system/sshd{,-second}.service

4）编辑单元文件sshd-second.service
修改描述字段
Description=OpenSSHserversecondinstancedaemon
添加sshd.service服务在After关键字以后：
After=syslog.targetnetwork.targetauditd.servicesshd.service
移除sshdkey建立：
ExecStartPre=/usr/sbin/sshd-keygen移除这一行
在执行脚本里，添加第二sshd服务的配置文件：
ExecStart=/usr/sbin/sshd-D-f/etc/ssh/sshd-second_config$OPTIONS
修改后的sshd-second.service文件内容以下：

[Unit]
Description=OpenSSHserversecondinstancedaemon
After=syslog.target network.targe tauditd.service sshd.service
[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config$OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
[Install]
WantedBy=multi-user.target

5）若是使用SELinux，添加tcp端口，负责第二sshd服务的端口就会被拒绝绑定：

~]#semanage port -a -tssh_port_t -p tcp22220

6）设置开机启动并测试：

~]#systemctl enable sshd-second.service
~]$ssh -p 22220 user@server

确保防火墙端口也开放。

（6）修改已经存在的单元文件

systemd单元配置文件默认保存在/usr/lib/systemd/system/目录，系统管理员不建议直接修改这个目录下的文件，自定义的文件在/etc/systemd/system/目录下，若是有扩展的需求，可使用如下方案：
建立一个目录/etc/systemd/system/unit.d/，这个是最推荐的一种方式，能够参考初始的单元文件，经过附件配置文件来扩展默认的配置，对默认单元文件的升级会被自动升级和应用。
从/usr/lib/systemd/system/拷贝一份原始配置文件到/etc/systemd/system/，而后修改。复制的版本会覆盖原始配置，这种方式不能增长附件的配置包，用于不须要附加功能的场景。
若是须要恢复到默认的配置文件，只须要删除/etc/systemd/system/下的配置文件就能够了，不须要重启机器，使用以下命令应用改变就能够：

systemctl daemon-reload

daemon-reload选项从新加载因此单元文件并从新建立依赖书，在须要当即应用单元文件改变的时候使用。另外，也可使用下面的命令达到一样的目的：

init q

还有，若是修改的是一个正在运行服务的单元文件，服务须要被重启下：

systemct lrestart name.service

（7）扩展默认单元配置文件配置

为了扩展默认的单元文件配置，须要先在/etc/systemd/system/下建立一个目录，用root执行相似下面的命令：

mkdir/etc/systemd/system/name.service.d

在刚才建立的目录之下建立配置文件，必须以.conf文件结尾。
例如建立一个自定义的依赖文件，内容以下：

[Unit]
Requires=new_dependency
After=new_dependency

另一个例子，能够配置重启的时候，在主进程退出后30秒在重启，配置例子以下：

[Service]
Restart=always
RestartSec=30

推荐每次只产生一个小文件，每一个文件只聚焦完善一个功能，这样配置文件很容易被移除或者连接到其余服务对的配置目录中。
为了应用刚才的修改，使用root执行如下操做：

systemctldaemon-reload
systemctlrestartname.service

例子：扩展httpd.service服务配置
为了是httpd服务启动的时候执行用户自定义的脚本，须要修改httpd的单元配置文件，执行如下几步操做，首先建立一个自定义文件的目录及自定义文件：

~]#mkdir/etc/systemd/system/httpd.service.d
~]#touch/etc/systemd/system/httpd.service.d/custom_script.conf

假设自定义文件位置在/usr/local/bin/custom.sh，将这个信息添加到custom_script.conf自定义脚本中：

[Service]
ExecStartPost=/usr/local/bin/custom.sh

应用更改：

~]#systemctldaemon-reload
~]#systemctlrestarthttpd.service

12.单元实例化

在运行的时候有可能须要将一个模版实例化好几个单元，@字符用于标识模版和单元文件的关系，实例化单元能够从另一个单元文件（使用Requires或者Wants选项），或者使用systemctlstart命令。实例化服务单元能够按照下面的方式命名：

template_name@instance_name.service

几个实例能够指向同一个模板文件配置选项常见的全部实例，举个例子，一个单元配置文件的Wants选项能够是：

Wants=getty@ttyA.service,getty@ttyB.service

首先让systemd搜索给定服务单位，若是没有发现，systemd忽略@和点号之间的部分，直接搜索getty@.service服务文件，读取配置，并启动服务。
通配符字段，称为单元说明符，能够在任何单元配置文件使用。单位说明符替代某些单位在运行时参数和解释。经常使用的单元说明符说明以下：
%n整个单元名字，包括类型的后缀，%N是相同的意义，可是ASCII取代为禁止字符。
%p前缀名字，在实例化的时候，%p表明@字符前面的部分。
%i实例名字，@字符和单元类型直接的部分。%I是相同的意义，可是ASCII取代为禁止字符。
%H主机名字，当配置文件被加载的时候的主机名。
%t运行时目录，当前的运行目录，对root用户就是/run目录，对于无特权用户就是XDG_RUNTIME_DIR变量指定的目录。
举个例子，getty@.service包含下面的结构：

[Unit]
Description=Gettyon%I
...
[Service]
ExecStart=-/sbin/agetty--noclear%I$TERM
...

当getty@ttyA.service和getty@ttyB.service实例化的时候，Description=被解释为“GettyonttyA”和"GettyonttyB"。

13.VNC SERVER配置

安装：

yum install tigervnc-server

配置：

（1） 复制配置文件：

~]# cp /lib/systemd/system/vncserver@.service \
/etc/systemd/system/vncserver@.service

（2） 编辑配置文件：

ExecStart=/sbin/runuser -l USER -c "/usr/bin/vncserver %i -geometry 1280x1024"
PIDFile=/home/USER/.vnc/%H%i.pid

将USER换成要使用的VNC服务的用户，好比root:

ExecStart=/sbin/runuser -l root -c "/usr/bin/vncserver %i"

若是要修改分辨率能够修改geometry内容，其余不须要作修改。
而后保持配置。

（3）使用systemctl命令，强制从新读取配置文件：

~]# systemctl daemon-reload

（4）配置vncserver密码

vncpasswd

（5）若是有两个用户但愿同时使用vnc，须要配置两份配置文件：
 vncserver-USER_1@.service 及 vncserver-USER_2@.service，文件内容同root用户的配置方法
而后为两个用户建立vnc密码：

~]$ su - USER_1
~]$ vncpasswd
Password:
Verify:
~]$ su - USER_2
~]$ vncpasswd
Password:
Verify:

（6）启动vnc服务

systemctl start vncserver@:10

为了开机启动，使用以下命令：

systemctl enable vncserver@:10
ln -s '/etc/systemd/system/vncserver@.service' \
'/etc/systemd/system/multi-user.target.wants/vncserver@:10.service'

（7） 关闭进程

systemctl disable vncserver@:display_number.service
systemctl stop vncserver@:display_number.service

参考文档：

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/index.html

https://www.ibm.com/developerworks/cn/linux/1407_liuming_init1/