0

一台安装了Linux操作系统的计算机的启动，从BIOS加电开始，随后进入Bootloader，由Bootloader加载Linux内核并初始化。

内核本身不能做任何有意义的事情，内核初始化的最后一步，就是创建PID为1、名为init的守护进程，该进程是操作系统中所有用户进程的祖先——所有用户进程都由它创建。

所谓Init机制，就是确定了init进程行为的一套规范及其实现（此实现通常就反应在/sbin/init上）。Linux发展到今天，依次出现了sysvinit、upstart 、systemd三种广泛应用的Init机制。

sysvinit就是System V风格的初始化机制，它来源于System V风格的UNIX。绝大部分Linux发行版均兼容sysvinit。

sysvinit引入了运行级别（runlevel ）的概念，不同模式下需要进行的系统初始化工作不一样。各发行版对运行级别的定义各有不同，但是通常：0表示关机、1表示单用户模式、6表示重启。

sysvinit正常启动（单用户或者GUI模式）系统时，大致执行的工作流如下：

1. 读取/etc/inittab获得需要进入的运行级别
2. 依次执行：
   1. 执行rc.sysinit脚本，完成一些重要的系统初始化工作，例如：设置系统时钟、设置定义在/etc/sysctl.conf中的内核参数、启用swap、挂载文件系统等
   2. 执行rc*.d中的脚本，其中*为运行级别。被执行的脚本均以S开头，S后面的数字表示其被执行的顺序
   3. 执行rc.local脚本
   4. 如果需要，启动X显示管理器

sysvinit正常关闭（关机或者重启）系统时，则以数字顺序，执行rc*.d中的K开头的脚本。

sysvinit在启动、关闭时均是串行的执行各脚本的，这一方面让问题排查简单，一方面则导致运行速度缓慢。

很多Linux发行版为sysvinit配套了管理工具，例如service、chkconfig等。

参考Linux运行级别和启动顺序了解sysvinit的更多知识。

从2.6版本的内核开始，即插即用被良好的支持，Linux被越来越多的用在个人计算机领域，这让sysvinit面临两个问题：

1. 串行化、阻塞的初始化过程导致启动消耗的时间长，而个人计算机却经常性的重启
2. 一次性启动所有系统服务浪费很多资源，而即插即用要求按需启动、卸载服务

早期的Ubuntu版本（6.10+）即启用了upstart这一init机制，以解决上述问题。

upstart是一个事件驱动的init机制，例如，当U盘插入到接口时，内核会通知upstart，后者会进行挂载操作。upstart的优势包括：

1. 能够很好的实现即插即用——当新硬件被发现时动态启动服务，硬件被拔出时停止服务
2. 提高系统启动速度，一方面减少启动时的工作量，一方面事件驱动改变了串行话的执行方式

1. 执行内部的初始化
2. 触发一个名为startup 的特殊事件，该事件会触发系统剩余部分的初始化
3. init进程触发定义在/etc/init/mountall.conf的任务mountall，这是因为mountall声明了start on startup 
4. mountall进一步触发若干事件：local-filesystem、virtual-filesystem、all-swaps
5. local-filesystem导致udev的执行，后者导致upstart-udev-bridge的执行
6. local-filesystem发布filesystem事件、upstart-udev-bridge发布net-device-up IFACE=lo，这两个事件导致rc-sysinit的执行
7. rc-sysinit导致telinit的执行，后者发布runlevel事件
8. runlevel事件导致rc的执行，rc负责读取/etc/rc*.d中的脚本并执行

很多现有的服务已经基于System V风格的Init脚本来编写，Upstart必须兼任它。尽管Upstart完全是基于任务+事件的，但是它模拟了对运行级别的支持。

修改/etc/init/rc-sysinti.conf中的DEFAULT_RUNLEVEL可以改变默认的“运行级别”。在启动过程中，rc任务会根据设置的运行级别，访问系统中的sysvinit脚本。

Job就是一个明确定义的工作单元，它可以启动一个系统服务，或者运行一个配置命令。每个Job都会等待一个或者多个事件，一旦事件发生，upstart就会触发Job完成工作。

Job可以分为三种类型：

根据Job的作用范围，可以将其分为系统级服务、会话级服务。后者仅为某个用户服务。

在Job的生命周期中，它可以处于以下状态之一：

事件是一个通知，由Upstart发送给所有订阅者（任务或者其它事件），管理员随时可以手工的触发事件：

initctl emit myevent

一个Job的启动/停止行为，可能是其它Job启动/停止行为的结果，这是依靠事件来驱动的。Upstart提供了一系列特殊事件（starting、started、stopping、stopped），用来广播Job的状态转换。尽管某些Job状态的名称与事件名称相同，但是它们不是一回事。

根据产生、消费方式的不同，事件分为：

initctl emit --no-wait mysignal

系统中预定义的事件取决于发行版，可以执行man 7 upstart-events 查看之。 

Job需要进行的工作由一个配置文件描述，该文件位于/etc/init目录中，以.conf结尾。

配置文件由多个小节（stanza） 构成，小节定义Job某个方面的特性：

kill signal INT
kill signal SIGINT

exec COMMAND [ ARG ]...
# 示例
# exec /usr/bin/my-daemon --option foo -v

pre-start exec|script
# 脚本可以具有多行内容
pre-start script
  # 在这里编写Shell脚本
  ...
  # 下面的这行脚本用于取消Job的启动
  stop ; exit 0
end script

# EVENT为事件的名称，可以指定多个事件，并用and或者or连接，支持用( ) 来限定逻辑操作的优先级
# KEY和VALUE可以用来限定环境变量，这些变量可以由事件定义，并传递给Job的小节
# VALUE支持fnmatch风格的通配符
# KEY和VALUE可以使用 != 表示不相等
start on EVENT [[KEY=]VALUE]... [and|or...]

# 在本地文件系统、非环回网卡准备好后，启动该Job
# 如果你的Job绑定了非0.0.0.0地址，则它需要在目标网卡启动后，才能启动
start on (local-filesystems and net-device-up IFACE!=lo)

# 在指定的运行级别启动Job
start on runlevel [2345]

# 在抽象任务network-services启动完毕之后，启动Job
start on started network-services

start on started other-service

start on starting other-service 

stop on EVENT [[KEY=]VALUE]... [and|or...]

stop on runlevel [016]
stop on stopping network-services
stop on stopped other-service

# 0和13视为正常退出
normal exit 0 13
# 如果因为SIGUSR1 SIGWINCH信号而退出，也视为正常
normal exit 0 13 SIGUSR1 SIGWINCH

# 最多重新启动limit次，每次启动间隔INTERVAL秒
respawn limit COUNT INTERVAL | unlimited
# 示例：
respawn limit 10 5
respawn limit unlimited

当开发自己的Job时，需要注意一下内容：

1. fork的次数需要声明：很多Linux后台服务基于Double fork实现守护进程，这必须在Job配置文件中声明
2. fork后即可用：你必须保证在Double fork后，服务立刻进入可用状态，因为Upstart基于fork计数判断服务是否就绪
3. 遵循SIGHUP要求：Upstart发送SIGHUP信号给Job后，期望Job的行为满足以下要求：
   1. 完成必要的重现初始化工作，例如重新读取配置文件
   2. Job必须使用现有的PID，即Job不能通过fork来实现reload
4. 遵循SIGTEM要求：Job收到此信号后，应当立即停止，并释放所有资源

这里我们讲解一下MySQL的Job定义：

# 任务的描述信息
description     "MySQL Server"
author          "Mario Limonciello <superm1@ubuntu.com>"

# 在2345运行级别启动服务
start on runlevel [2345]
# 在rc服务启动之前，如果目标运行级别是016则停止服务
stop on starting rc RUNLEVEL=[016]

# 当任务以外退出时重启，最多重启2次，间隔5秒
respawn
respawn limit 2 5
# 设置整个文件内可见的变量
env HOME=/etc/mysql
# 设置进程的umask
umask 007

# 延长强杀超时，因为MySQL刷出缓冲需要时间
kill timeout 300

pre-start script
    # 在启动前的准备工作，普通Shell脚本，略
    # 访问变量的语法与Bash相同
    $HOME
end script

# 主逻辑脚本
exec /usr/sbin/mysqld

post-start script
   # 启动后的清理工作
end script

和Upstart相关的命令包括：initctl，关于此命令的细节请参考Linux命令知识集锦。

Systemd是主流Init系统中最新的一个，是Upstart的竞争者。值得注意的是，作为Upstart起源的Ubuntu从15.04版本开始，也改用了Systemd。

Systemd具有以下特点：

1. 兼容SysVinit或者 LSB initscripts
2. 提供比Upstart更加激进的并行启动能力，通过socket / D-Bus activation等技术启动服务，速度更快
3. 提供按需启动的能力
4. 利用cgroup跟踪进程的生命周期，比Upstart基于PID的方式更加高效。在fork时，子进程会遍历父进程的cgroup，Systemd通过遍历cgroup可以把服务相关的所有进程都正确的停止掉
5. 内建挂载服务，以便自动挂载U盘、光盘，不再需要安装autofs服务
6. 事务性的依赖管理，Systemd在最大程度上保证并发启动的同时，确保那些有明确依赖顺序的服务（例如NFS依赖网络），按照顺序启动
7. 内建日志服务journald，可以代替syslog，克服了syslog的一系列缺点

Systemd把系统启动过程中的每一项工作，例如：

1. 启动后台服务，例如SSHD
2. 执行系统配置，例如挂载文件系统

等都抽象为一个配置单元，它们的角色类似于Upstart的Job。配置单元被划分为不同的类型：

每个配置单元都有一个对应的配置文件，例如MySQL服务对应mysql.service。配置文件的语法比起System V脚本要简单的多。

Systemd尽量的保证了并发启动，但是某些任务之间存在天然的依赖关系，不能通过套接字激活（socket activation）、D-Bus激活、autofs这三种方法来解除依赖。为了满足先后启动的需要，Systemd允许在配置文件中声明单元的依赖关系。

要声明一个强依赖，可以使用A require B 的语法，声明弱依赖则使用A want B 。如果服务之间存在依赖循环，则先去掉弱依赖，如果循环仍然存在，则Systemd会报错。

前面我们提到过target这类特殊的配置单元，用于分组其它配置单元。利用Target把sysvinit某个运行级别中需要启动的所有服务归纳到同一个组中，可以很方便的模拟运行级别。Systemd预定义了运行级别和Target之间的映射：

Systemd通过并行加速启动过程，要提高并行度，必须解除服务之前的依赖关系。Systemd通过三种手段来解除依赖，这三种手段都基于延迟（Lazy）启动的思想。

绝大部分服务之间的依赖是套接字依赖——被依赖者（A）的套接字（S）必须准备好监听，依赖者（B）才能启动。传统的Init机制都是启动A，然后再启动B。

Systemd的想法是，直接启动S，当B第一次向S发起连接时，延迟的启动A。能让服务A的套接字先于A本身启动，需要依靠内核的一个特性：子进程可以继承父进程的文件描述符（文件句柄，file descriptor） ，而套接字是一种文件句柄。因此先于A启动S的流程可以如下：

1. 由init进程创建套接字S，清空其close_on_exec位，以便允许它被子进程继承
2. 当B向S发起连接时，由init进程fork/exec出A的主进程
3. A的主进程自动获得套接字S

其实这种内核特性以前就被使用过，例如inetd。

所谓D-Bus即桌面总线（Desktop-bus），是一种低延迟、低开销、高可用的进程间通信机制。它被越来越多的用于应用程序之间的通信，以及应用程序与内核的通信。例如NetworkManager就使用D-Bus和其它应用程序交互。

D-Bus支持所谓Bus activation特性：如果A依赖于B的D-Bus服务，而B尚未运行，则D-Bus可以在A第一次请求B的时候，启动B。在B启动完毕之前A会一直等待。依赖于D-Bus的这一特性，也可以实现并行启动。

文件系统相关的活动是相当耗时的，因为与之相关的配置单元而导致串行化执行，会大大的拖累系统启动速度。

Autofs是一个实现按需挂载的软件，它利用了内核的automounter模块：当open()系统调用作用在/mnt/dsk/file1时，/mnt/dsk可能尚未挂载，此时内核将让open()调用挂起，并通知Autofs执行挂载，完毕后把控制权返回给open()调用。

Systemd在内部集成了Autofs的实现。对于系统中的挂载点它会在启动时创建一个临时的Mock，这样，依赖于此挂载点的服务就可以立即启动。当文件系统相关的配置单元都启动成功后，Systemd再把那些Mock替换为真正的挂载点。如果在文件系统尚未准备好时，Mock就被访问，Systemd则让访问者陷入等待。

Systemd允许用户管理自己控制下的服务 —— 启动、停止、禁用自己的配置单元，每个用户都具有自己Systemd实例。

用户级单元可以放在/usr/lib/systemd/user、 ~/.config/systemd/user等位置。

使用--user参数，systemctl管理当前用户的systemd单元：

systemctl --user enable myapp.service 

配置单元同样由文件文件来定义，命名格式为unitName.unitType （后缀为此配置单元的类型），存放路径取决于具体发行版，例如/etc/systemd/system，Ubuntu则存放在/lib/systemd/system目录中。

配置单元由一系列的段组成，格式类似于Windows下的INI文件。

Unit段：基础元数据和依赖关系

# 只有/etc/ssh/sshd_not_to_be_run文件不存在时，才运行此单元
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run 

Service段：专用于服务类单元的配置

ExecStartPre=-/bin/chmod 700       /run/thing

Install段：定义如何启动单元，是否开机启动

1. 后台服务不再需要使用Double fork来产生守护进程
2. 不要调用 setsid()，应该由Systemd处理
3. 不需要维护PID文件
4. Systemd提供了日志功能，服务进程只需要：
   1. 输出到stderr即可，取决于配置
   2. 打开systemd-cat管道并输出，例如 echo "message" | systemd-cat 
   3. 可以在服务脚本中调用log_daemon_msg、log_failure_msg、log_progress_msg、log_end_msg等LSB函数
5. 正确处理SIGTERM信号，立即停止当前服务
6. 正确处理SIGHUP信号，重新启动服务
7. 需要套接字的服务，不要自己创建，让Systemd传入
8. 调用sd_notify()函数告知Systemd服务本身状态的改变。当服务初始化完毕后进入就绪状态时，即可调用之 

Systemd支持模板化的Unit文件，用于从单个配置文件启动多个单元。调用模板化Unit时，需要使用特殊的@符号：<service_name>@<argument>.service。

其中argument是传递给模板的字符串，在模板文件中可以这样访问：

1. %i：进行转义的参数
2. %I：原样传递的参数

Ceph Mon就是这样的模板Unit：

[Unit]
Description=Ceph cluster monitor daemon

After=network-online.target local-fs.target time-sync.target
Wants=network-online.target local-fs.target time-sync.target

PartOf=ceph-mon.target

[Service]
LimitNOFILE=1048576
LimitNPROC=1048576
EnvironmentFile=-/etc/default/ceph
Environment=CLUSTER=ceph
; 访问参数
ExecStart=/usr/bin/ceph-mon -f --cluster ${CLUSTER} --id %i --setuser ceph --setgroup ceph
ExecReload=/bin/kill -HUP $MAINPID
PrivateDevices=yes
ProtectHome=true
ProtectSystem=full
PrivateTmp=true
TasksMax=infinity
Restart=on-failure
StartLimitInterval=30min
StartLimitBurst=5
RestartSec=10

[Install]
WantedBy=ceph-mon.target

在目录下有指向上述模板的符号链接，参数就是通过符号链接的名字传递的：

cd /etc/systemd/system#
ls ceph-mon.target.wants/ -la
# ceph-mon@xenon.service -> /lib/systemd/system/ceph-mon@.service
# ceph-mon@Xenon.service -> /lib/systemd/system/ceph-mon@.service

这里我们讲解一下MySQL的Unit定义：

# MySQL systemd service file

[Unit]
# 配置单元描述
Description=MySQL Community Server
# 声明依赖
After=network.target

[Install]
# 该服务在多用户模式下启动
WantedBy=multi-user.target

[Service]
User=mysql
Group=mysql
PermissionsStartOnly=true
# 启动服务之前需要运行的命令
ExecStartPre=/usr/share/mysql/mysql-systemd-start pre
# 启动服务主程序
ExecStart=/usr/sbin/mysqld
# 启动服务之后需要运行的命令
ExecStartPost=/usr/share/mysql/mysql-systemd-start post
TimeoutSec=600
Restart=on-failure
RuntimeDirectory=mysqld
RuntimeDirectoryMode=755

我们再看看multi-user.target这个配置单元组的定义：

[Unit]
Description=Multi-User System
Documentation=man:systemd.special(7)
# 该组被启动之前basic组必须被启动，同样的，basic停止前该组必须先停止
Requires=basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes

[Install]
# 为本单元组定义别名，调用systemctl命令时可以使用别名
Alias=default.target

和Systemd相关的命令包括：systemctl、journal、systemd-analyze、hostnamectl、localectl、timedatectl、loginctl等，关于此命令的细节请参考Linux命令知识集锦。