systemd详解

<

div id=”content” contentScore=”7114″>CentOS 6和之前版本采用SysVinit的系统启动进程管理体系，一般用户都可通过在/etc/inittab文件的配置，来个性化自己的系统启动序列。但也经常会由于特殊环境的硬件等关系问题，造成其串行的启动进程控制流，因为可能任务的阻塞而影响启动过程。

CentOS 7开始使用SystemD,所以我们必须要了解SystemD.

详细介绍请参阅: RedHat 产品文档
使用systemd管理服务: Chapter 6. Managing Services with systemd

一、 SystemD起源
SystemD是Linux下的一种init软件，由Lennart Poettering带头开发，并在LGPL 2.1及其后续版本许可证下开源发布。Lennart是redhat员工，但SystemD不是redhat项目。其开发目标是提供更优秀的框架以表示系统服务间的依赖关系，并依此实现系统初始化时服务的并行启动，同时达到降低Shell的系统开销的效果，最终代替现在常用的System V与BSD风格init程序。
SystemD这一名字源于Unix中的一个惯例：在Unix中常以“d”作为系统守护进程（英语：daemon，亦称后台进程）的后缀标识。除此以外，SystemD亦是借代英文术语D体系，而这一术语即是用于描述一个人具有快速地适应环境并解决困难的能力。
SystemD被设计用来改进SysVinit的缺点，与Ubuntu的upstart形成技术竞争。SystemD的很多概念来源于苹果的launchd。目标是尽可能启动更少进程；尽可能将更多进程并行启动（这是性能优于SysVinit的理念基础）。SystemD尽可能减少对Shell脚本的依赖。传统SysVinit使用inittab来决定运行哪些Shell脚本，大量使用Shell脚本被认为是效率低下无法并行的原因。SystemD使用了Linux专属技术，不再顾及POSIX兼容，只要能满足社会变革的需要，突破一些可能过时的技术约束，这也是当今创信理念的需要，相信市场会给出评判。
与多数发行版使用的System V风格init相比，SystemD采用了以下新技术：
●    采用Socket激活式与总线激活式服务，以提高相互依赖的各服务的并行运行性能；
●    用cgroups代替PID来追踪进程，因此即使是两次fork之后生成的守护进程也不会脱离systemd的控制。
从设计构思上说，由于SystemD使用了cgroup与fanotify等组件以实现其特性，所以只适用于Linux。有鉴于此，基于kFreeBSD分支的软件源无法纳入SystemD。

Linux 引导方式systemd upstart sysV http://www.linuxidc.com/Linux/2014-01/95555.htm

为什么systemd会被如此迅速的采用？ http://www.linuxidc.com/Linux/2014-08/105789.htm

systemd 与 sysVinit 彩版对照表 http://www.linuxidc.com/Linux/2014-09/106455.htm

Linux Systemd——在RHEL/CentOS 7中启动/停止/重启服务 http://www.linuxidc.com/Linux/2014-08/105975.htm

太有用了！用systemd命令来管理Linux系统！  http://www.linuxidc.com/Linux/2014-09/106490.htm

二、 SystemD 的工具
用SystemD初始化工具（init tool）来启动系统。SystemD 含了自己的配置和诊断工具，在使用它处理系统启动问题时用到的技巧不同于SysVinit。
SystemD初始化工具虽面世不久，却已成为一些发行版中默认使用的初始化工具；一些其他的发行版把它包含进来，作为upstart和SysVinit的替代品。由于它与upstart和SysVinit的兼容特性，在使用这两个初始化工具的发行版里面熟悉的命令与技巧也适用于SystemD。但是，为了能够真正利用好这个新的初始化系统的功能，系统管理员也需要了解SystemD的工具与参数。
给SystemD传达命令的主要工具是systemctl，它是一个命令行程序。该工具在改变配置文件或重新启动后台程序时需要root权限，但即使是非root用户也能下达一些诊断的命令。如果在启动该命令时不加任何参数，会看到一个系统启动时执行任务的“单位（unit）”列表，包括挂载及检测磁盘、启动后台服务及配置硬件。
服务（service）单位是最重要的一类单位之一，因它管理着后台服务，而在使用SysVinit的发行版里则一般使用初始化脚本来启动这些服务。
挂载（mount）与自动挂载（automount）单位用来挂载文件系统。
套接字（socket）单位用来创建套接字，并在访问套接字后，立即利用依赖关系间接地启动另一单位。
可使用参数让systemctl只列出某个类型的单位，如所有的服务单位：
systemctl –type=service
SystemD自动将其输出结果递交给less显示,列表中:
第一栏是单位的名字;
第二栏则表示该单位的定义是否已由SystemD正确加载。
第三栏则为该单位是否正在运行。如果使用了-a参数，那么该程序将仅显示非正在运行的单位，即已安装但并未在启动时使用的单位，同时也包含引导系统未能正常加载的单位文件。
第四栏则给出了当前状态：“exited”表示该进程已经无任何错误地完成，这种情况适用于,诸如进程在启动后并不在后台继续运行的情况，例如，在系统启动时由于考虑到兼容性因素执行在SysVinit里面常用的/etc/rc.d/rc.local文件的服务单位。“Running”表示正在后台运行的服务，如cron、dbus、sshd和udev。
第五栏是对该单位的描述。标有“LSB”或“SYSV”的单位已由systemd自动创建以管理传统启动脚本。
不能启动或启动后崩溃的服务在第四栏中用红色标为“failed”。可用如下命令来察看该服务是何时崩溃的以及在服务程序结束后提供了什么错误代码：
systemctl status ntpd.service
systemctl会列出包含文本终端的登录进程（agetty）的服务型单位。因为SystemD不同于Sysvinit，它会像管理普通的后台服务一样以服务单位的形式对这些进程进行管理。

1. SystemD服务管理
   systemctl is-enabled .service                  #查询服务是否开机启动
   sudo systemctl enable .service                  #开机运行服务
   sudo systemctl disable .service                #取消开机运行
   sudo systemctl start .service                  #启动服务
   sudo systemctl stop .service                    #停止服务
   sudo systemctl restart .service                #重启服务
   sudo systemctl reload .service                  #重新加载服务配置文件
   systemctl status .service                      #查询服务运行状态
   systemctl –failed                              #显示启动失败的服务

2. 开机模块加载
   /etc/modules-load.d/.conf，相当于原rc.conf中的MODULES变量
   模块黑名单仍在/etc/modprobe.d/下，如blacklist.conf:

3. Locale
   /etc/locale.conf，相当于原rc.conf中的LOCALE

4. 日志服务
   systemd自带日志服务，参考systemd Journal
   可以删除syslog-ng了

5. 主机名
   /etc/hostname，相当于原来rc.conf中的HOSTNAME变量

6. 网络
   还是用NetworkManager工具

更夼/div>