前言
systemd 是Linux 下的一种init 软件,由Lennart Poettering 带头开发,并在LGPL 2.1 及其后续版本许可证下开源发布。其开发目标是提供更优秀的框架以表示系统服务间的依赖关系,并依此实现系统初始化时服务的并行启动,同时达到降低Shell 的系统开销的效果,最终代替现在常用的System V 与BSD 风格init 程序。
init(为英语:initialization 的简写)是Unix 和类Unix 系统中用来产生其它所有进程的程序。它以守护进程的方式存在,其进程号为1。
关于init 的基础介绍请阅读wikipedia [init 条目](https://en.wikipedia.org/wiki/Init)
Systemd由于众多出色的特性以及良好的兼容性已经被各大发行版采用作为默认init程序,例如openSUSE(12.1+)、Fedora(15+)、ArchLinux(2012-10-13+)等。Debian技术委员会经过投票( The Debian technical committee vote concludes )之后决定Debian的下一个版本Debian8(别名:jessie)中以Linux为内核的版本将转换到systemd。之后,基于Debian的下游发行版Ubuntu也宣布将切换到systemd。所以systemd将是下一代的init程序,有必要在debian 8发布之前对其进行详细的调研。
本文是以debian 8 为调研平台,systemd 为调研目标整理撰写而成,除去前言部分外,包含以下部分:
- 基础介绍
- systemd 基础介绍,systemd 相关基础概念与特性的介绍等。
- 启动分析
- 分析Linux 启动过程中systmed 启动部分。
- 详细介绍
- 对systemd 在系统管理、进程管理、设备管理、日志管理等等方面进行分点详细介绍。
- 附录
- debian7-8 目前已知的更新与变化。
通用初始化脚本的更新。- 其他升级注意事项
注1: 本文摘录和引用了大量其他资料,由于时间与人力限制未能一一注明来源。如要切实深入的了解systemd 某一部分的内容,建议您认真阅读对应章节后的参考链接所指向的内容。
注2:本文整理撰写以及进行systemd 的相关实验时,debian 8 还未冻结,实验平台为debian testing 分支,systemd 版本为208,所以部分内容日后看来准确性可能会有所偏差。
基础介绍
关于Systemd的基础介绍,强烈建议阅读IBM DeveloperWorks的《浅析Linux初始化init系统,第3部分: Systemd》一文,这篇文章通俗和全面的介绍了Systemd的主要特性以及与Systemd相关的概念。
关于Systemd的基础使用建议阅读Arch Wiki的《Systemd》这一条目,阅读完之后将对Systemd的基本管理与操作有个基础性的了解。
请您务必在完整阅读完以上两篇文章之后再阅读本文后续内容。
关于Systemd的基础使用建议阅读Arch Wiki的《Systemd》这一条目,阅读完之后将对Systemd的基本管理与操作有个基础性的了解。
请您务必在完整阅读完以上两篇文章之后再阅读本文后续内容。
启动分析
通过上文的基础介绍之后,您应该对Systemd 有一个基础性的了解,本节将介绍Linux(with systemd) 的启动过程中与Systemd 相关的部分,希望您在阅读本节之后可以对Systemd 的工作原理与流程有一个全局的概念。
Linux(with systemd) 启动过程
- BIOS
- POST
- Boot Sequence
- MBR
- Boot loader
- eg Grub
- Kernel
- initrd
- Systemd
- ...
本文将主要介绍在第4 步骤向第5 步骤过渡的过程以及第5 步骤之后的过程。
Kernel -> Systemd
Kernel 将完成系统与硬件的检测与驱动初始化,在以rw 的方式挂载根文件系统(switch root)。Kernel 需要通过虚拟的文件系统–initrd 向用户空间的/sbin/ init 过渡。
关于initrd
"Initrd ramdisk 或者initrd 是指一个临时文件系统,它在启动阶段被Linux 内核调用。initrd 主要用于当“根” 文件系统被挂载之前,进行准备工作" -- Wikipedia
重点关注initrd 如何向systemd 进行转移。手动解压后查看init 脚本内容(注:debian 目前使用的是cpio 格式的initrd):
内核加载成功之后,首先运行的是/sbin/init 程序。
而/sbin/init 实际上是/lib/systemd/sytemd 的软链接,即switch root 之后其实直接开始运行systemd 程序.
接下来将介绍启动任务交接给systemd 的后续情况。
Systemd bootup process
/sbin/init(systemd) 是第一个运行的程序,它的进程编号PID=1,其他所有的进程都是从它衍生,都是它的子进程。
Target (Not Just Runlevel)
要了解systemd 的启动过程,需要先了解systemd 中相对于以往旧的init 软件新引入的target。
启动级别(runlevel)是一个旧的概念。现在,systemd引入了一个和启动级别功能相似又不同的概念——目标(target)。不像数字表示的启动级别,每个目标都有名字和独特的功能,
并且能同时启用多个。一些目标继承其他目标的服务,并启动新服务。systemd提供了一些模仿sysvinit启动级别的目标,仍可以使用旧的telinit启动级别命令切换。
—Archlinux Wiki它们本身实际上并不做什么,只是引用其他 unit(unit 是 systemd 的配置 单元,包含.service,.mount,.scokets 等)而已。这样便可以对 unit 做一个 统一的控制。(例如:multi-user.target 相当于在传统使用 SysV 的系统中运 行级别 5);bluetooth.target 只有在蓝牙适配器可用的情况下才调用与蓝牙 相关的服务,如:bluetooth 守护进程、obex 守护进程等)
更多介绍:
对于常见的 runlevel:0,1,2,3,4,5,6,systemd 都有对应的 target 与之 对应,不同的 target 与不同的服务相关,启动时候进入默认的 target,即可带起下属 的服务。
-Fedora Wiki
由上图可知每个 SvsV 的启动级别与之对于的 Systemd target,另 外 systemd 一般还会有一个默认的 target(default.target),这个 target 是上表中的 某一个 target 的软链接,表示默认的启动级别,等同于 /etc/inittab 文件中的 initdefault 值。
相对于/etc/rc[0~6].d,Systemd 采用target 来管理不同的服务,同时也是对服务进行抽象和分层管理的一种方式。除了以上表中的target ,还有不同的target。例如graphical.target 依赖着multi-user.target, multi-user.target 依赖着basic.target,
basic.target 依赖着 sysinit.target...具体 target 的依赖关系后文分析。
看一个例子,即可明白这种关系:
basic.target 依赖着 sysinit.target...具体 target 的依赖关系后文分析。
看一个例子,即可明白这种关系:
basic.target requires sysinit.targe
basic.target wants sockets.target、timer.target、paths.targt
Bootup
当systemd 启动系统时, 它首先会激活default.target, 从而激活其下属依赖的服务。下图体现了常见的启动逻辑.
- local-fs-pre.target: 本地设备挂载之前执行的target,用于执行挂载前的任务。
- local-fs.target:在执行这个此target之前会执行systemd-fstab-generator ,将/etc/fstab转换为systemd的unit。本target主要执行磁盘挂载、扫描等任务。
- swap.target: 挂载交换分区。
- cryptsetup.target: 执行磁盘加密任务。
- sysinit.target: 包含early boot 的所有任务。
- timers.target:timers 是systemd 中类似cron 的单元,此target 配置所有timer 任务。
- paths.target:path 是systemd 中使用inotify API 的单元,监视目录或文件的变更而触发任务,此target 配置所有path 任务。
- sockets.target: 配置所有socket 单元。
- resue.target: 触发系统恢复服务。
- basic.target: 包含启动的基础单元。
- emergency.target: 触发急救模式的任务。
- multi-user.target: 配置多用户模式。
- graphical.target: 执行登录的图形界面任务。
- 更完整的target介绍: systemd.special
另外在 systemd 中还有.wants 这个文件夹,一个 target 可能需要若干服务,需将 这些服务 ln -s 到与这个 target 同名的.wants 文件夹中.
例如我们写了一个 ABC.service, 在文件中指明了依赖的服务和启动先后顺序,只 需要将 ABC.targt ln -s 到合适的.wants 文件中即可。
例如我们写了一个 ABC.service, 在文件中指明了依赖的服务和启动先后顺序,只 需要将 ABC.targt ln -s 到合适的.wants 文件中即可。
Bootup in the Initial RAM Disk (initrd)
本节参考自: Bootup in the Initial RAM Disk (initrd)(具体细节待补充, 现阶段 debian 未采用这种方式)。
在上文中我们提到在initrd阶段,init脚本启动了/sbin/init(systemd),而实际上在initrd中可以直接启用systemd。
initrd中默认的target将是initrd.target,系统启动直到bacsic.target之前的过程都与上文的类似,从这点之后systemd激活了一个特殊的initrd.target。
如果根设备可以挂在到/sysroot,sysroot.mout单元将被激活,到达initd-root-fs.tatrget。之后initrd-parse-etc.service将扫描/sysroot/etc/ fstab,为了找到/usr的挂载点。
所有找到的项目将会被挂在到/sysroot之下,到达initrd-fs.target 。initrd-cleanup.service独立与initrd-switch-root.target运行。
最后一步,initrd-switch-root.service被激活,系统switch root到/sysroot。
initrd中默认的target将是initrd.target,系统启动直到bacsic.target之前的过程都与上文的类似,从这点之后systemd激活了一个特殊的initrd.target。
如果根设备可以挂在到/sysroot,sysroot.mout单元将被激活,到达initd-root-fs.tatrget。之后initrd-parse-etc.service将扫描/sysroot/etc/ fstab,为了找到/usr的挂载点。
所有找到的项目将会被挂在到/sysroot之下,到达initrd-fs.target 。initrd-cleanup.service独立与initrd-switch-root.target运行。
最后一步,initrd-switch-root.service被激活,系统switch root到/sysroot。
关机过程
关机的过程同样也是激活某些相关的target,完成磁盘的卸载、进程的退出等等清理工程.
本节参考链接
- 计算机是如何启动的?
- Linux 的启动流程
- man bootup
- 详解linux系统的启动过程及系统初始化
- Inside the Linux boot process
- Linux startup process
- Arch wiki:systemd
- The initrd Interface of systemd
- Debian:The system initialization
-----------------------------------------
systemctl对服务的操作
设置开机启动
对于那些支持Systemd的软件,安装的时候,会自动在
/usr/lib/systemd/system
目录添加一个配置文件(一般为.service
后缀)。
配置文件的后缀名,就是该Unit的种类,比如
sshd.socket
。如果省略,Systemd默认后缀名为.service
,所以nginx
会被理解成nginx.service
。
如果你想让该软件开机启动,就执行下面的命令(以nginx.service为例):
上面的命令相当于在
/etc/systemd/system/
目录添加一个符号链接nginx.service
,指向/usr/lib/systemd/system/nginx.service
。
这是因为开机时,Systemd只执行
/etc/systemd/system/
目录里面的配置文件。这也意味着,如果把修改后的配置文件放在该目录,就可以达到覆盖原始配置的效果。
但要注意,符号链接可能不是直接在
/etc/systemd/system/
目录下,而是在该目录下的multi-user.target.wants/
目录中。启动服务
设置开机启动以后,软件并不会立即启动,必须等到下一次开机。如果想现在就运行该软件,那么要执行以下命令:
为了查看nginx服务是否真的启动了,可以查看一下它的状态:
输出结果:
● nginx.service - nginx - high performance web server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since 二 2019-03-26 03:06:39 CST; 1 weeks 1 days ago
Docs: http://nginx.org/en/docs/
Main PID: 4084 (nginx)
Tasks: 3
Memory: 34.0M
CGroup: /system.slice/nginx.service
├─ 4084 nginx: master process /usr/local/openresty/nginx/sbin/nginx -c /usr/lo...
├─25383 nginx: worker process
└─25384 nginx: cache manager process
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
- Loaded行:配置文件的位置,表示是否设为开机启动,enabled表示已经设置为开机自启动。
- Active行:表示是否处于激活状态(即是否正在运行)
- Docs行:该软件的文档,有可能是一个网址,有可能是man(意思是让你用man命令查看)
- Main PID行:主进程PID
- Tasks行:表示一共有几个子进程
- Memory行:表示该服务占用的内存大小
- CGroup块:应用的所有子进程
- 日志块:应用的日志
停止服务
终止正在运行的服务,需要执行systemctl stop命令:
有时候,该命令可能没有响应,服务停不下来。这时候就不得不”杀进程”了,向正在运行的进程发出kill信号:
当然,我们自己用
ps -ef | grep nginx
找到pid,然后自己用kill -9 pid
也是可以的重启服务
读懂配置文件
一个服务怎么启动,完全由它的配置文件决定。下面就来看,配置文件有些什么内容。
前面说过,配置文件主要放在
/usr/lib/systemd/system
目录,也可能在/etc/systemd/system
目录。找到配置文件以后,使用文本编辑器打开即可。systemctl cat
命令可以用来查看配置文件,下面以sshd.service
文件为例,它的作用是启动一个SSH服务器,供其他用户以SSH方式登录。
可以看到,配置文件分成几个区块,每个区块包含若干条键值对。下面依次解释每个区块的内容。
[Unit]区块:启动顺序与依赖关系
- Description:当前服务的简单描述
- Documentation:文档位置,有可能是一个网址,有可能是
man
,意思是让你用man命令去查。 - After:表示如果network.target或sshd-keygen.service需要启动,那么sshd.service应该在它们之后启动。
相应地,还有一个Before字段,定义sshd.service应该在哪些服务之前启动。
注意:After和Before字段只涉及启动顺序,不涉及依赖关系。
举例来说,某Web应用需要mysql数据库储存数据。在配置文件中,它只定义要在 mysql之后启动,而没有定义依赖mysql。上线后,由于某种原因,mysql需要重新启动,在停止服务期间,该Web应用就会无法建立数据库连接。
设置依赖关系,需要使用Wants字段和Requires字段。
– Wants:表示sshd.service与sshd-keygen.service之间存在”弱依赖”关系,即如果”sshd-keygen.service”启动失败或停止运行,不影响sshd.service继续执行。
– Wants:表示sshd.service与sshd-keygen.service之间存在”弱依赖”关系,即如果”sshd-keygen.service”启动失败或停止运行,不影响sshd.service继续执行。
Requires字段则表示”强依赖”关系(由于sshd没有强依赖,所以在这里并没有写Requies字段),即如果该服务启动失败或异常退出,那么sshd.service也必须退出。
注意,Wants字段与Requires字段只涉及依赖关系,与启动顺序无关,默认情况下是同时启动的。
[Service] 区块:启动行为
Service区块定义如何启动当前服务。
启动命令
许多软件都有自己的环境参数文件,该文件可以用
EnvironmentFile
字段读取。
EnvironmentFile字段:指定当前服务的环境参数文件。该文件内部的key=value键值对,可以用
$key
的形式,在当前配置文件中获取。
上面的例子中,sshd的环境参数文件是
/etc/sysconfig/sshd
。ExecStart
:定义启动进程时执行的命令,配置文件里面最重要的字段是ExecStart。
上面的例子中,启动sshd,执行的命令是
/usr/sbin/sshd -D $OPTIONS
,其中的变量$OPTIONS
就来自EnvironmentFile
字段指定的环境参数文件。
与之作用相似的,还有如下这些字段。
- ExecReload字段:重启服务时执行的命令
- ExecStop字段:停止服务时执行的命令
- ExecStartPre字段:启动服务之前执行的命令
- ExecStartPost字段:启动服务之后执行的命令
- ExecStopPost字段:停止服务之后执行的命令
请看下面的例子。
上面这个配置文件,第二行ExecStart设为空值,等于取消了第一行的设置,运行结果如下。
execstart2
post1
post2
所有的启动设置之前,都可以加上一个连词号(-),表示”抑制错误”,即发生错误的时候,不影响其他命令的执行。比如,
EnvironmentFile=-/etc/sysconfig/sshd
(注意等号后面的那个连词号),就表示即使/etc/sysconfig/sshd
文件不存在,也不会抛出错误。启动类型
Type字段定义启动类型。它可以设置的值如下:
- simple(默认值):ExecStart字段启动的进程为主进程
- forking:ExecStart字段将以
fork()
方式启动,此时父进程将会退出,子进程将成为主进程 - oneshot:类似于simple,但只执行一次,Systemd会等它执行完,才启动其他服务
- dbus:类似于simple,但会等待D-Bus信号后启动
- notify:类似于simple,启动结束后会发出通知信号,然后Systemd再启动其他服务
- idle:类似于simple,但是要等到其他任务都执行完,才会启动该服务。一种使用场合是为让该服务的输出,不与其他服务的输出相混合
下面是一个oneshot的例子,笔记本电脑启动时,要把触摸板关掉,配置文件可以这样写。
上面的配置文件,启动类型设为oneshot,就表明这个服务只要运行一次就够了,不需要长期运行,但是你有没有发现,停止了之后,无法用systemctl开启呀,所以我们可以再改成以下这样:
可以看到,上面配置文件中添加了ExecStop和RemainAfterExit。
当执行start后,就关闭了触控板(有人可能会觉得奇怪,start不是开启触摸板么?怎么会关闭呢?但你要看清楚,被执行的命令是
当执行start后,就关闭了触控板(有人可能会觉得奇怪,start不是开启触摸板么?怎么会关闭呢?但你要看清楚,被执行的命令是
touchpad-off
,start表示执行touchpad-off
这个命令,当然就是关闭触控板)RemainAfterExit
字段的值可以为true或false,也可以用yes和no。
这个字段可能比较多人不懂,它设为yes的意思是“程序虽然退出了,但仍然让
systemctl status
命令查询到的状态为active
”,为什么要这样呢?因为只有这样才可以执行stop操作,假如你本身就是stop状态,你是没法执行systemctl stop
操作的(实际上你去执行它是不会报错的,但按原则来说,只有状态为active的服务才能stop)。
有人会觉得,既然执行之后就自己退出了,对程序来说实际上已经
RemainAfterExit这个配置主要是提供给一些并非常驻内存的程序使用。
stop
了,为什么还要stop呢?很明显,本例的stop并不是指“/usr/bin/touchpad-off”这个服务的stop,而是指“/usr/bin/touchpad-off start”的“反操作”而已。RemainAfterExit这个配置主要是提供给一些并非常驻内存的程序使用。
重启行为
Service区块有一些字段,定义了重启行为。
KillMode字段:定义Systemd如何停止sshd服务。
上面这个例子中,将KillMode设为process,表示只停止主进程,不停止任何sshd 子进程,即子进程打开的 SSH session 仍然保持连接。这个设置不太常见,但对sshd很重要,否则你停止服务的时候,会连自己打开的SSH session一起杀掉(这样你就再也无法远程连接去启动它了,所以不能这么做,sshd这点比较特殊)。
KillMode字段可以设置的值如下:
- control-group(默认值):当前控制组里面的所有子进程,都会被杀掉
- process:只杀主进程
- mixed:主进程将收到SIGTERM信号,子进程收到SIGKILL信号
- none:没有进程会被杀掉,只是执行服务的stop命令。
接下来是Restart字段。
Restart字段:定义了sshd退出后,Systemd的重启方式。
Restart字段:定义了sshd退出后,Systemd的重启方式。
上面的例子中,Restart设为on-failure,表示任何意外的失败,就将重启sshd。如果sshd正常停止(比如执行systemctl stop命令),它就不会重启。
Restart字段可以设置的值如下。
- no(默认值):退出后不会重启
- on-success:只有正常退出时(退出状态码为0),才会重启
- on-failure:非正常退出时(退出状态码非0),包括被信号终止和超时,才会重启
- on-abnormal:只有被信号终止和超时,才会重启
- on-abort:只有在收到没有捕捉到的信号终止时,才会重启
- on-watchdog:超时退出,才会重启
- always:不管是什么退出原因,总是重启
对于守护进程,推荐设为
on-failure
。对于那些允许发生错误退出的服务,可以设为on-abnormal
。
RestartSec字段:表示Systemd重启服务之前,需要等待的秒数。上面的例子设为等待42秒。
[Install]区块
Install区块,定义如何安装这个配置文件,即怎样做到开机启动。
WantedBy字段:表示该服务所在的Target。
Target的含义是服务组,表示一组服务。WantedBy=multi-user.target指的是,sshd所在的Target是multi-user.target。
这个设置非常重要,因为执行
systemctl enable sshd.service
命令时,sshd.service的一个符号链接,就会放在/etc/systemd/system目录下面的multi-user.target.wants子目录之中。
Systemd有默认的启动Target,使用以下命令查看:
一般来说,常用的Target有两个:一个是multi-user.target,表示多用户命令行状态;另一个是graphical.target,表示图形用户状态,它依赖于multi-user.target。官方文档有一张非常清晰的Target依赖关系图。
Target的配置文件
注意,Target 配置文件里面没有启动命令。
上面输出结果中,主要字段含义如下。
- Requires字段:要求basic.target一起运行。
- Conflicts字段:冲突字段。如果rescue.service或rescue.target正在运行,multi-user.target就不能运行,反之亦然。
- After:表示multi-user.target在basic.target 、 rescue.service、 rescue.target之后启动,如果它们有启动的话。
- AllowIsolate:允许使用systemctl isolate命令切换到multi-user.target。
修改配置文件后重启
修改配置文件以后,需要重新加载配置文件,然后重新启动相关服务。