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. 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分钟的超时机制。