清单 3. sysvinit rc 2 脚本的简化 upstart 脚本

initctl 工具提供了类似于 telinit 的功能，不过增加了一些特定于 upstart 的特性。initctl用来启动或终止作业、列表作业、以及获取作业的状态、发出事件、重启 init 进程，等等。正如您前面看到的一样，您可以使用 initctl 和 emit 选项为 upstart 生成一个事件。list 选项让您可以通过标识作业状态来深入了解系统操作。它告诉您目前正在等待哪些服务，以及哪些服务目前是活动的。initctl 工具还可以显示用于调试而接收的事件。
Upstart的事件数量是没有限制的，但init守护进程和telinit工具定义了一组常用的标准事件。主要有：
starting: 当作业被调度并开始运行时，由Upstart触发。
started: 当作业正在运行时被触发。
stopping: 当作业开始终止时被触发。
stopped: 当作业已经完成时（成功或失败）被触发。
当upstart init进程启动时，它会发出startup事件，这将激活实现了System V兼容性的事件和runlevel事件。随着作业的启动和停止，init守护进程将触发starting, started, stopping, stopped事件。另一个核心事件shutdown则是在系统关闭时发出的。其他核心事件包括ctrlaltdel，它说明您按下了Ctrl-Alt-Delete，或kbdrequest，它用来说明您按下了 Alt-Up（向上箭头）键组合。
以Upstart自己的启动过程为例，其流程如下（Ubuntu中）：
1）Upstart执行内部初始化。
2）Upstart自己触发一个单一的称为startup的事件。这个事件触发其余的系统初始化过程。注意没有"startup"作业（因此没有/etc/init/startup.conf文件）。
3）init运行mountall作业（/etc/init/mountall.conf），因为mountall作业中有"start on startup"配置节，满足触发后运行的条件。
4）mountall作业依次触发一系列的事件，包括local-filesystems, all-swap等。
下面是mountall.conf的内容：
从内容可以看出，mountall作业用来以正确的顺序挂载文件系统。在mountall作业执行完之后，由于触发了filesystem事件，Upstart接着会去执行rc-sysinit作业，它负责生成System v兼容的runlevel事件。前面我们已经分析过，Ubuntu在rc-sysinit作业中处理inittab并切换到initdefault级别来运行（Fedora是在rcS作业中完成）。
Upstart有三种事件类型：
Signal Event: 非阻塞的，即异步的。触发信号型事件会立即返回，调用者继续往下执行。信号型的意思就是广播者并不关心谁会接收它，也不需要等待是否发生某种事情，它只是用来提供信息，用作通信。使用带--no-wait选项的initctl emit命令来创建信号型事件。例如initctl emit --no-wait mysignal。注意事件触发的非阻塞特性并不会直接影响那些与此事件有关的作业，它只是影响触发者程序，允许其继续执行，而无需等待任何使用这个事件的作业。作业本身的非阻塞特性则会影响作业自己，它使得作业不能被终止或延迟，不能以任何形式持有触发者的操作。
Method Event: 阻塞的，即同步的。它通常与Task job结合使用。方法型事件的行为类似于编程语言中的method或function call，调用者需要等待这个工作的完成。例如initctl emit mymethod，这个方法型事件被同步地触发，调用者需要等待直到initctl命令完成。在mymethod事件上启动的任务可能运行成功，也可能失败，假设有一个作业/etc/init/myapp.conf，如下：
你应该启动myapp作业，并检查这个“方法”是否正常完成：
# inictl emit mymethod ACTION=do_something
[ $? -ne 0 ] && { echo "ERROR: myapp failed"; exit1; }
Hook Event: 阻塞的，即同步的。钩子介于信号和方法之间。它是一种通知，表示系统发生了一些改变，不同于信号，钩子型事件的触发者需要等待作业的完成。因此钩子通常用来标志即将发生的改变一些事情。starting和stopping是钩子型事件，被Upstart触发以表明作业即将启动或即将终止。
注意事件与状态是有区别的，虽然Upstart内部使用状态（这些状态可以通过initctl status和list命令显示给用户看），但事件是配置文件指定作业期望行为的一种方式，starting, started, stopping, stopped是事件，不是状态。这些事件在一些特殊的状态转移发生之前触发。例如，starting事件在与此事件相关的作业实际进行运行队列之前被触发。
（3）作业环境：
env KEY=VALUE: 定义一个缺省的环境变量，其值可以被启动作业的事件或命令覆盖。
export KEY: 把环境变量的值导出到starting, started, stopping, stopped事件中。
（4）服务、任务和重生（respawning）
默认情况下，作业是一个服务，这意味着当作业正在运行时，启动作业的动作就被认为执行完了，当事件以0状态码退出时，服务将重新启动。
task: 这个配置节指定作业是一个任务，而不是服务。这意味着启动作业的动作直到作业本身已经运行或停止了，才算是完成，当事件以0状态码退出时，表示任务执行完成，不再重启。注意start命令和任何starting, stopping事件将被阻塞，直到一个服务正在运行或一个任务已经完成。
respawn: 这个配置节表示服务或任务如果非正常终止，将自动启动。除stop命令外的终止都是非正常的终止。
（5）实例
默认情况下，在同一时间任何作业只允许有一个实例存在，尝试再次启动一个正在运行的作业将导致错误。通过用配置节instance NAME定义不同的实例名，可以允许作业有多个实例存在。只要正在运行的实例中没有同名的，就允许启动这个实例。例如：
（6）文档和外部工具相关
主要的配置节有description, author, version, emits。
（7）进程环境
主要的配置节有console, umask, nice, oom, chroot, chdir, limit等。
console output|owner: 作业的标准输入、输出和错误文件描述符默认是连接到/dev/null的，指定本节则将它们连接到系统控制台/dev/console。若设置了owner，还会作业设为系统控制台的owner，这意味着当按下某些组合键如Ctrl+C时，作业会从内核中接收到相关的信号。
umask UMASK: 设置文件模式掩码。
（8）作业生命周期
启动一个作业的流程：
1）Upstart把作业的目标从stop改成start。正如目标的名字指示的一样，作业（实例）现在尝试启动。目标可以用initctl list和status命令显示。
2）Upstart触发starting事件，指示作业即将启动。这个事件包括两个环境变量：JOB指定作业名；INSTANCE指定实例名，如果启动单一的实例（没有instance配置节），则实例名为空。
3）starting事件完成。
4）如果pre-start节存在，则产生pre-start进程。如果pre-start失败，Upstart把目标从start改成stop，设置表示失败的变量并触发stopping和stopped事件。
5）Upstart产生主进程。即运行script或exec配置节，如果没有script或exec配置节，则Upstart什么也不做。
6）Upstart确定作业的最终PID，可参考expect fork和expect守护r进程。
7）如果post-start配置节存在，则产生post-start进程。。如果post-start失败，Upstart把目标从start改成stop，设置表示失败的变量并触发stopping和stopped事件。
8）Upstart触发started事件。这个事件包含与starting同样的环境变量。对Service job，当started事件完成后，主进程即完全地运行起来了。如果是Task job，则任务执行完成（成功或失败）。
终止一个作业的流程：
1）Upstart把作业的目标从start改为stop。现在作业（实例）尝试终止。
2）如果pre-stop配置节存在，则产生pre-stop进程。如果pre-stop失败，Upstart设置表示失败的变量，并触发stopping和stopped事件。
3）如果作业有script或exec配置节，则终止主进程，首先向主进程发送SIGTERM信号，然后Upstart等待kill timeout秒数（默认为5秒），如果进程仍然在运行，则向进程发送SIGKILL信号，因为进程不能选择忽略此信号，因此能保证进程被终止。
4）Upstart触发stopping事件。这个事件有一系列的相关环境变量，包括：
JOB: 与本事件关联的作业名。
INSTANCE: 实例名。
RESULT: "ok"表示作业正常退出，"failed"表示作业失败，注意退出结果的显示可以用normal exit配置节修改。
PROCESS: 导致作业失败的配置节名称。如果RESULT=ok，则本变量不会被设置。如果设置了，可能值有pre-start, post-start, main(表示script或exec配置节), pre-stop, post-stop, respawn(表示作业产生次数超过了respawn limit配置节设置的限制)。
EXIT_STATUS或EXIT_SIGNAL: 如果作业自己退出则设置EXIT_STATUS，如果由于接收到信号退出则设置EXIT_SIGNAL。如果两个变量都没有设置，则进程在产生的过程中出现了问题（例如指定要运行的命令没有找到）。
5）如果post-stop配置节存在，则生成post-stop进程。如果post-start失败，Upstart设置表示失败的变量并触发stopped事件。
6）Upstart触发stopped事件。当stopped事件完成后，作业即完全终止。stopped事件与stopping事件有相同的环境变量集。
（9）运行级别
Debian/Ubuntu系统的运行级别如下：
0：系统关闭。
1：单用户模式。
2：多用户的包括网络的图形界面模式（默认）。
3：与2相同，但未使用。
4：与2相同，但未使用。
5：与2相同，但未使用。
6：系统重启。
还有两个伪运行级别：
N：以前的运行级别不能确定。
S：单用户模式的别名。
显示运行级别可用runlevel命令，改变运行级别可用reboot, shutdown或telinit。改变默认运行级别可修改rc-sysinit.conf中的DEFAULT_RUNLEVEL变量的值，或在内核启动命令行中加入
DEFAULT_RUNLEVEL=1之类的参数。    传统上，默认运行级别被编码在/etc/inittab中，然而这个文件在Upstart中不再使用（但是为了向后兼容，Upstart仍然支持它）。
（10）系统启动
在前面我们详细地分析过init启动系统的过程（以Fedora为例子），这里我们以Ubuntu为例子，并从Upstart的视角来阐述。在系统引导时，当initramfs文件系统运行起来时（用于设置RAID、解锁加密的文件系统卷等），将会运行/sbin/init并分配PID为1，这样Upstart接过控制权。在默认运行级别2上的启动流程如下：
1）Upstart执行内部的初始化。
2）Upstart触发一个单一的称为startup的事件，这个事件触发其余的系统初始化过程。
3）init运行一些指定了start on startup的作业。这其中最著名的就是mountall作业，用来挂载硬盘和文件系统。
4）mountall作业依次触发一系列的事件，包括local-filesystems, virtual-filesystems, all-swaps等。当系统设备和挂载点可用时，它运行mountall守护程序来完成挂载硬盘和文件系统的工作。
5）virtual-filesystems事件引发udev作业启动。它运行uded守护程序来管理系统的设备，并监控设备的改变。
6）udev作业引发upstart-udev-bridge作业启动。
7）upstart-udev-bridge作业将会在某个点处触发"net-device-up IFACE=lo"事件，以表示本地网络（例如IPv4的127.0.0.0）可用。
8）在最终的文件系统挂载之后，mountall将会触发filesystem事件。
9）由于rc-sysinit作业中有start on filesystem and net-device-up IFACE=lo节，Upstart将会启动rc-sysinit作业（Fedora中没有这个作业，而是仍然由传统的rc-sysinit脚本完成工作）。
10）rc-sysinit作业最后调用telinit命令，格式为 telinit "${DEFAULT_RUNLEVEL}"。
11）telinit命令触发runlevel事件，即执行runlevel RUNLEVEL=2 PREVLEVEL=N。注意这就是telinit所做的全部工作，它自己并不会切换运行级别，而通过runlevel程序实现。
12）runlevel事件引发很多其他的Upstart作业启动，包括/etc/init/rc.conf，它用来启动遗留的SystemV init系统。
（11）系统关闭
在系统关闭过程中，有一些重要的事实需要知道：
1）Upstart决不会关闭自己。Upstart会在系统断电时终止，如果它之前终止过，说明是一个bug。
2）Upstart决不会终止没有stop on配置节的作业。
3）Ubuntu既使用Upstart作业，也使用SysV作业。核心的服务由Upstart处理，一些额外的服务可以在遗留的SystemV模式下运行。这主要是为向后兼容，因此在Ubuntu的Universe和Mutiverse软件库中有大量的软件包，为避免更改每个软件包以使它能在Upstart下工作，Upstart允许使用已经存在的SystemV（还包括Debian兼容的）脚本。
关闭系统需要先执行关机动作，例如在图形用户界面中单击"Shut Down..."，运行命令shutdown -h now等。关机的流程如下：
1）假设当前运行级别为2，关机动作将会使Upstart触发runlevel事件，即 runlevel RUNLEVEL=0 PREVLEVEL=2。
2）作业/etc/init/rc.conf将被运行。这个作业调用/etc/init.d/rc，并传递新的运行级别（“0“）。
3）SystemV系统调用/etc/rc0.d/中必要的脚本（都是指向/etc/init.d/中脚本的链接），来终止SystemV服务。
4）其中有一个/etc/init.d/sendsigs脚本，这个脚本中有个do_stop()函数，它负责杀死所有没有被终止的进程（包括Upstart进程）。
（12）系统重启
先要执行重启动作，例如在图形界面中单击"Restart..."，运行shutdown-r now 或reboot。重启的流程如下：
1）假设当前运行级别为2，重启动作将会使Upstart触发runlevel事件，即 runlevel RUNLEVEL=6 PREVLEVEL=2。
2）作业/etc/init/rc.conf将被运行。这个作业调用/etc/init.d/rc，并传递新的运行级别（“6“）。
3）SystemV系统调用/etc/rc6.d/中必要的脚本（都是指向/etc/init.d/中脚本的链接），来终止SystemV服务。
4）其中有一个/etc/init.d/sendsigs脚本，这个脚本中有个do_stop()函数，它负责杀死所有没有被终止的进程（包括Upstart进程）。
（13）恢复模式
Ubuntu提供了恢复模式以应对系统出现问题的情况。这由friendly-recovery软件包来处理。
总的来说，Upstart是传统init的一个有趣的替代程序，并且具有一些独特的优点。实际上已经不存在什么理由再使用运行级别了，因为系统将充分利用硬件进行引导。任何没有给出的硬件都不会触发需要它的任务。Upstart 也可以很好地处理热插拔设备。例如，如果在完成系统引导很长时间以后插入了一块 PCMCIA 网卡，那就会生成 network-interface-added 事件。这个事件会引起动态主机配置协议（Dynamic Host Configuration Protocol，DHCP）作业来对这个网卡进行配置，生成一个 network-interface-up事件。当为这个新接口分配一个默认路由时，会生成一个 default-route-up 事件。此时，需要网络接口的作业（例如邮件服务器或 Web 服务器）就可以自动启动（如果接口消失，这些服务将会自动停止）。
编译和安装 upstart 非常简单，并且遵循典型的 configure、make 和 make install 模式。 Upstart 提供了一组示例作业，它们与典型的 init 配置兼容。与 initng 类似，新应用程序必须要根据需求编写自己的作业（可能还需要添加新事件）。不管怎样，部署新的 init 系统都会有一些风险。不过 upstart 的优点当然值得去冒这些风险并执行其他必要的操作。
正如上面介绍的一样，initctl 工具提供了人们对 telinit 所期望的功能。不过 initctl 也为跟踪和调试提供了附加功能。