CentOS上的Linux1.12安装之后，使用了systemctl enable docker和systemctl start docker来进行处理。大多数跟我一样老的人，可能更习惯使用service start。作为接受的点赞和吐槽几乎都是很多的Systemd，已经是以风卷残云之势涤荡着占据linux世界很多年的SysVinit原本固若金汤的地位。docker本身就是基于linux内核特性发展而来，学习的时候顺便学习一下关联到的路人甲技术Systemd也算得上是顺便打个酱油吧。

systemd的作者就是这个呆萌的80后小哥. Systemd被很多人定义为A modern service manager for Linux, 既然是modern， 那么古代的service manager for linux是什么呢？
毫无疑问：SysVinit。OS启动起来之后，linux/unix的进程号为1的进程是一个非常特殊的进程，它的特殊在于它是其他所有进程最终的根，所有的进程都是由init派生而出，当进程树中某一进程意外阵亡如果没有对这种情形下子进程怎样处置有所设定，一般其子进程即成为孤儿进程，作为进程整理的管理者，init责无旁贷地肩负着处理这些进程的任务，而这些进程的父进程也自然而然的变成了init。这种情况在linux/unix的世界经常发生，IPC编程有经验的话也会很清楚地知道那个两次fork可以脱离进程管理树的魔术。而Systemd使用了cgroup则可以处理这个问题。除了这些，init因为是顺序地处理整体的service，所以速度自然不是很快，而systemd则是采用了并行方式的处理，大大提升了boot的速度。而且，systemd也已经不再满足于init以前做的仅仅是服务管理的这一角色，它把触角伸到很多地方，这也是被大多数人所诟病的根本原因，说systemd像一个怪兽一样，增加了越来越多的功能，担心其耦合会导致形成一个不可控的庞然大物，这根unix的KISS哲学也是格格不入。说得太多容易引起争论，不管它有多不好，CoreOS/CentOS/Debian等主流Linux都开始引入Systemd也是一个现实。老实讲，我对这一点充满期待，技术和设计里面再强大也战胜不了现实的世界，而一旦形成了统一的标准，不管好坏，它将能引导这个现实的世界。

Systemd的整体构成

与SysVinit不同的时候，Systemd不仅仅局限于init作的那些事情，从下面的systemd的整体构成中便可以略见一斑。

systemctl

systemctl可能是被直接接触到的systemd的最多的命令了，通过它可以做很多事情，从服务的管理到电源的控制等。

Unit相关命令

在SysVinit中被认定为service的，在Systemd里面大致接近于Unit的概念。systemctl start docker所操作的也是docker的Unit。

Unit File相关

和SysVinit的启动脚本类似，Systemd也有它的相关文件，只不过与init的启动脚本可直接执行不太相同，它更多地通过设定来完成。docker在centos7上安装之后，systemctl enable docker的命令实际上只是做了一个链接，以确保系统再次重启的时候会做systemctl start docker这个操作，这一点与Init时代的rc.X目录所作的事情完全一致，但是systemd无疑作了更多，下面列出一些和unit file相关的命令，Unit file的详细在后面的文章中会详细讲解。

系统命令

从休眠/重启到确认系统状态都提供了systemd的命令。

job相关

环境变量相关

除此之外，systemctl还有snapshot的创建/删除等等相关命令，不再一一列举，但是作为systemd最常用的CLI命令，相信已经看到它的触角伸得到哪里了，而且应该还在不断的进化中。