initctl 与正在运行的 Upstart 初始化守护进程通信。只有确认相关 PID 命名空间确实运行 Upstart 后，才能使用它；如果当前主机使用 systemd，应改用 systemd 的原生工具。
初始化 · 第 4 课
Upstart 作业
学习如何在确认使用旧式 Upstart 的系统上通过 `initctl` 检查和控制作业。
列出并解读作业状态
列出已知的作业及其实例：
$ initctl list
检查单个作业：
$ initctl status networking
networking start/running
Upstart 会同时报告 start 或 stop 这样的目标，以及 running 或 waiting 这样的当前状态。stop/waiting 表示该作业没有运行，正在等待启动条件或手动请求；它不一定表示发生了错误。
Upstart 状态输出中的 stop/waiting 通常表示什么？
启动和停止作业
检查依赖关系和影响后，可执行：
$ sudo initctl start JOB_NAME
$ sudo initctl stop JOB_NAME
作业可以定义由环境变量区分的多个实例。在这种情况下，应提供配置要求的确切变量，并在查询或停止实例时始终带上这些变量。启动网络、存储、身份验证或远程访问作业可能中断当前会话，因此要保留通过控制台恢复的手段。
哪个命令会手动请求启动 peanuts 作业？
重启与配置变更
用以下命令请求重启一个正在运行的作业：
$ sudo initctl restart peanuts
在 Upstart 中，编辑作业文件后执行 restart，并不总是等同于使用新配置完整执行一次 stop 再 start：正在运行的作业可能仍以原有配置为准。请先验证修改后的 .conf 文件，再按照已安装版本对应的方法让 Upstart 重新加载配置；如果必须让新配置生效，则应遵循文档规定的停止/启动流程。
重启会造成服务中断，而且服务可能无法恢复运行。之后应检查实际服务端点和日志。
哪个命令会请求重启正在运行的 Upstart 作业 peanuts？
验证作业配置
安装修改后的作业文件之前，应使用旧发行版提供的验证工具（通常是 init-checkconf），并检查所包含的脚本、环境变量、用户/组设置、重新拉起策略以及事件表达式。然后按照相应版本的 initctl reload-configuration 流程重新加载定义。
语法验证无法证明路径确实存在、凭据允许执行、事件一定会到达，或进程最终会进入就绪状态。请在具备恢复手段的环境中测试。
作业语法验证无法证明什么？
谨慎发出事件
Upstart 可以发出指定名称的事件：
$ sudo initctl emit EVENT_NAME
启动或停止表达式与之匹配的每个作业都可能作出响应。事件并非只发送给某个作业，而且其影响可能通过后续事件层层扩散。发出自定义事件或系统事件前，应检查所有匹配的配置；不要在生产主机上随意重放核心启动事件。
运行 initctl emit EVENT_NAME 时可能发生什么？
课程已完成
你已完成 Upstart 作业
现在，你可以在明确理解状态和事件作用范围的前提下操作 Upstart 作业。
分别解读
initctl输出中的目标和状态。评估影响后，启动或停止确切的作业实例。
将重启与作业配置变更视为两个不同的问题。
验证语法后，再测试运行时就绪状态。
发出事件前，检查每一个可能匹配的表达式。