按下电源键，随着风扇转动的声音，显示器上开启的图标亮起。之后，只需要静静等待几秒钟，登录界面显示，输入密码，即可愉快的玩耍了。
简单地说，从BIOS或者UEFI开始读取硬盘。接下来，进入bootloader(LILO或者GRUB)，bootloader开始载入内核，内核初始化完毕后，紧接着进入用户空间的初始化。
这些都是通过一个核心配置文件tab(/etc/init)和一组启动脚本以及符号链接集执行的，本质上为系统提供了合理的启动顺序，
他的好处是依赖关系简单，任务之间泾渭分明的一个一个启动，即使某个基础服务出了错也便于排查。但也正因为如此，他的启动性能很不好。
服务无法并行启动不说，而且只能按照预先规定的顺序启动服务。如果你安装了新的硬件或者新服务，他不提供及时支持的标准方法。
我们把用户空间init的服务分别叫做Job A、Job B...图1可以看到，在SysV init之下，服务必须一个接一个的顺序启动，前面的服务初始化完毕，后面才可以开始。因此，启动时间就是所有服务启动时间之和。
他的改进版Upstart在此基础上就做了优化——互不相关的服务可以并行启动，这样启动总时间就等于时间消耗最大的一组服务，而不是所有服务之和。systemd在并行启动上采取了比Upstart更加激进的方案
图2是systemd的并行启动方式，他让配置所有的服务同时启动。如果Job Aing依赖Job B怎么办呢？首先两个Job是同时启动的，A如果先启动，就向B发送请求服务，B会先将请求缓存起来，等到B初始化完毕之后，再处理缓存的请求。
相比SysV init，这也带来了不确定性，即你不知道此时到底哪些服务起了，哪些没起，全依赖系统管理
其中runlevel2/3/4都属于同一个运行等级(multi-user)，而系统的默认的运行等级为5——graphical。我们平时所用的桌面环境就是这个等级了。其实，现代大部分采用systemd的发行版都和这个大同小异。
如果你对.target文件，和他的定义语法很迷惑，没有关系，后面还会详细解释。我举这个例子，只是想让你了解systemd是兼容systemV的运行等级概念的。所以，你关于SystemV的认识也是可以继续沿用的
systemd不光负责处理进程和服务，同时还能挂载文件系统、监控网络套接字等等。在systemd中
所有服务和功能都被抽象成一个个单元(Unit)，根据功能不同，单元类型也不同。systemd正是通过配置这些单元
上面的尤其是服务单元我们会经常打交道，而且必要时也可以自定义服务单元等。比如我们的蓝牙功能就抽象成
使用deepin15.7的过程中，遇到过一个bug，就是在系统长期休眠之后再重启，蓝牙模块莫名其妙的关闭了，进入[设置]面板也
在systemd中一个.service就是一个服务类型的配置单元，同时也代表了一个服务功能。
表示当前单元在列出的单元之前启动。比如Before=bar.service，说明当前单元在bar.service之前启动。
ConditionPathExists,表示在后面的路径存在时返回true,这里使用了!非运算符，应该是取反的意思。
EnvironmentFile,指定当前服务环境参数文件，内部使用键值对定义，可以使用$key读取值，比如后面的$SSHD_OPTS
ExecReload，表示重启服务时执行的命令。其他的诸如ExecStop等等，望文生义即可
最后一个比较重要的是Type字段，定义启动类型。notify，表示启动结束后会发出通知信号，然后 Systemd 再启动其他服务。
同时multi-user.target是系统的默认target，在启动该target的时候，他下面的服务都会开机启动。
target文件只是组织一批服务，因此他没有[service]、[mount]等定义启动或者挂载的区块
Wants是比较重要的依赖关系，他不会将启动错误扩散给其他单元。systemd文档鼓励我们多用Wants关系
systemd 自带日志服务 journald，该日志服务的设计初衷是克服现有的 syslog 服务的缺点。
Systemd Journal 用二进制格式保存所有日志信息，用户使用 journalctl 命令来查看日志信息。无需自己编写复杂脆弱的字符串分析处理程序。
关于自定义单元的首要一点建议：不要更改/lib/systemd/system(系统单元目录)，他由系统维护。
